| Internet-Draft | RI-RSVP FRR Bypass | May 2024 |
| Ramachandran, et al. | Expires 2 November 2024 | [Page] |
The RSVP-TE Fast Reroute extensions specified in RFC 4090 defines two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnel. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout and hence make facility backup method refresh-interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 November 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
RSVP-TE relies on periodic refresh of RSVP messages to synchronize and maintain the Label Switched Path (LSP) related states along the reserved path. In the absence of refresh messages, the LSP-related states are automatically deleted. Reliance on periodic refreshes and refresh timeouts are problematic from the scalability point of view. The number of RSVP-TE LSPs that a router needs to maintain has been growing in service provider networks and the implementations should be capable of handling increase in LSP scale.¶
[RFC2961] specifies mechanisms to eliminate the reliance on periodic refresh and refresh timeout of RSVP messages and enables a router to increase the message refresh interval to values much longer than the default 30 seconds defined in [RFC2205]. However, the protocol extensions defined in [RFC4090] for supporting Fast Reroute (FRR) using bypass tunnels implicitly rely on short refresh timeouts to cleanup stale states.¶
In order to eliminate the reliance on refresh timeouts, the routers should unambiguously determine when a particular LSP state should be deleted. In scenarios involving [RFC4090] FRR using bypass tunnels, additional explicit tear down messages are necessary. Refresh-interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in this document consists of procedures to enable LSP state cleanup that are essential in supporting RI-RSVP capability for [RFC4090] FRR using bypass tunnels.¶
Base RSVP [RFC2205] maintains state via the generation of RSVP Path/Resv refresh messages. Refresh messages are used to both synchronize state between RSVP neighbors and to recover from lost RSVP messages. The use of Refresh messages to cover many possible failures has resulted in a number of operational problems.¶
The problems listed above adversely affect RSVP control plane scalability and RSVP-TE [RFC3209] inherited these problems from standard RSVP. Procedures specified in [RFC2961] address the above-mentioned problems by eliminating dependency on refreshes for state synchronization and for recovering from lost RSVP messages, and by eliminating dependency on refresh timeout for stale state cleanup. Implementing these procedures allows implementations to improve RSVP-TE control plane scalability. For more details on eliminating dependency on refresh timeout for stale state cleanup, refer to "Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling Techniques [RFC8370].¶
However, the facility backup protection procedures specified in [RFC4090] do not fully address stale state cleanup as the procedures depend on refresh timeouts for stale state cleanup. The updated facility backup protection procedures specified in this document, in combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this dependency on refresh timeouts for stale state cleanup.¶
The procedures specified in this document assume reliable delivery of RSVP messages, as specified in [RFC2961]. Therefore, this document makes support for [RFC2961] a pre-requisite.¶
The reader is expected to be familiar with the terminology in [RFC2205], [RFC3209], [RFC4090], [RFC4558], [RFC8370] and [RFC8796].¶
Phop node: Previous-hop router along the label switched path¶
PPhop node: Previous-Previous-hop router along the label switched path¶
Nhop node: Next-hop router along the label switched path¶
NNhop node: Next-Next-hop router along the label switched path¶
PLR: Point of Local Repair router as defined in [RFC4090]¶
MP: Merge Point router as defined in [RFC4090]¶
LP-MP node: Merge Point router at the tail of Link-Protecting bypass tunnel¶
NP-MP node: Merge Point router at the tail of Node-Protecting bypass tunnel¶
TED: Traffic Engineering Database¶
LSP state: The combination of "path state" maintained as Path State Block (PSB) and "reservation state" maintained as Reservation State Block (RSB) forms an individual LSP state on an RSVP-TE speaker¶
RI-RSVP: The set of procedures defined in Section 3 of RSVP-TE Scaling Techniques [RFC8370] to eliminate RSVP's reliance on periodic message refreshes¶
B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object defined in Summary FRR extensions [RFC8796] and is added by the PLR for each protected LSP.¶
RI-RSVP-FRR: The set of procedures defined in this document to eliminate RSVP's reliance of periodic message refreshes when supporting facility backup protection [RFC4090]¶
Conditional PathTear: A PathTear message containing a suggestion to a receiving downstream router to retain the path state if the receiving router is an NP-MP¶
Remote PathTear: A PathTear message sent from a Point of Local Repair (PLR) to the MP to delete the LSP state on the MP if PLR had not previously sent the backup Path state reliably¶
E
/ \
/ \
/ \
/ \
/ \
/ \
A ----- B ----- C ----- D
\ /
\ /
\ /
\ /
\ /
\ /
F
In the topology in Figure 1, let us consider a large number of LSPs from A to D transiting B and C. Assume that refresh interval has been configured to be long of the order of minutes and refresh reduction extensions are enabled on all routers.¶
Also let us assume that node protection has been configured for the LSPs and the LSPs are protected by each router in the following way¶
In the above condition, assume that B-C link fails. The following is the sequence of events that is expected to occur for all protected LSPs under normal conditions.¶
While the above sequence of events has been described in [RFC4090], there are a few problems for which no mechanism has been specified explicitly.¶
The purpose of this document is to provide solutions to the above problems which will then make it practical to scale up to a large number of protected LSPs in the network.¶
The solution consists of five parts.¶
A node supporting facility backup protection [RFC4090] MUST set the RI-RSVP flag (I bit) that is defined in Section 3.1 of RSVP-TE Scaling Techniques [RFC8370] only if it supports all the extensions specified in the rest of this document. Hence, this document updates [RFC4090] by defining extensions and additional procedures over facility backup protection [RFC4090] in order to advertise RI-RSVP capability [RFC8370]. However, if a node supporting facility backup protection [RFC4090] does set the RI-RSVP capability (I bit) but does not support all the extensions specified in the rest of this document, then it leaves room for stale state to linger around for an inordinate period of time given the long refresh intervals recommended by [RFC8370] or disruption of normal FRR operation. Procedures for backward compatibility (see Section 4.6.2.3 of this document) delves on this in detail.¶
As per the facility backup procedures [RFC4090], when an LSP becomes operational on a node and the "local protection desired" flag has been set in the SESSION_ATTRIBUTE object carried in the Path message corresponding to the LSP, then the node attempts to make local protection available for the LSP.¶
With regard to the PLR procedures described above and that are specified in [RFC4090], this document specifies the following additional procedures to support RI-RSVP [RFC8370].¶
A Node-ID based RSVP-TE Hello session is one in which Node-ID is used in the source and the destination address fields of RSVP Hello messages [RFC4558]. This document extends Node-ID based RSVP Hello session to track the state of any RSVP-TE neighbor that is not directly connected by at least one interface. In order to apply Node-ID based RSVP-TE Hello session between any two routers that are not immediate neighbors, the router that supports the extensions defined in the document MUST set TTL to 255 in all outgoing Node-ID based Hello messages exchanged between the PLR and the MP. The default hello interval for this Node-ID hello session MUST be set to the default specified in RSVP-TE Scaling Techniques [RFC8370].¶
In the rest of the document the term "signaling adjacency", or "remote signaling adjacency" refers specifically to the RSVP-TE signaling adjacency.¶
With regard to the MP procedures that are defined in [RFC4090] this document specifies the following additional procedures to support RI-RSVP defined in [RFC8370].¶
Each node along an LSP path supporting the extensions defined in this document MUST also include its router ID in the Node-ID sub-object of the RRO object carried in the Resv message of the corresponding LSP. If the PLR has not included a Node-ID sub-object in the RRO object carried in the Path message and if the PLR is in a different IGP area, then the router MUST NOT execute the MP procedures specified in this document for those LSPs. Instead, the node MUST execute backward compatibility procedures defined in Section 4.6.2.2 of this document as if the upstream nodes along the LSP do not support the extensions defined in this document.¶
A node receiving a Path message should determine whether the message contains a B-SFRR-Ready Extended Association object with its own address as the bypass destination address and whether it has an operational Node-ID signaling adjacency with the Association source. If the PLR has not included the B-SFRR-Ready Extended Association object or if there is no operational Node-ID signaling adjacency with the PLR identified by the Association source address or if the PLR has not advertised RI-RSVP capability in its Node-ID based Hello messages, then the node MUST execute the backward compatibility procedures defined in Section 4.6.2.2 of this document.¶
If a matching B-SFRR-Ready Extended Association object is found in in the Path message and if there is an operational remote Node-ID signaling adjacency with the PLR (identified by the Association source) that has advertised RI-RSVP capability (I-bit) [RFC8370], then the node MUST consider itself as the MP for the PLR. The matching and ordering rules for Bypass Summary FRR Extended Association specified in RSVP-TE Summary FRR [RFC8796] MUST be followed by the implementations supporting this document.¶
Once a router concludes it is the MP for a PLR running refresh-interval independent FRR procedures as described in the preceding section, it MUST create a remote path state for the LSP. The only difference between the "remote" path state and the LSP state is the RSVP_HOP object. The RSVP_HOP object in a "remote" path state contains the address that the PLR uses to send Node-ID hello messages to the MP.¶
The MP MUST consider the "remote" path state corresponding to the LSP automatically deleted if:¶
The purpose of "remote" path state is to enable the PLR to explicitly tear down the path and reservation states corresponding to the LSP by sending a tear message for the "remote" path state. Such a message tearing down "remote" path state is called "Remote" PathTear.¶
The scenarios in which a "Remote" PathTear is applied are described in Section 4.5 of this document.¶
This section describes the procedures that must be executed upon different kinds of failures by nodes along the path of the LSP. The procedures that must be executed upon detecting RSVP signaling adjacency failures do not impact the RSVP-TE graceful restart mechanisms ([RFC3473], [RFC5063]). If a node executing these procedures acts as a helper for a neighboring router, then the signaling adjacency with the neighbor will be declared as having failed only after taking into account the grace period extended for the neighbor by this node acting as a helper.¶
Node failures are detected from the state of Node-ID hello sessions established with immediate neighbors. RSVP-TE Scaling Techniques [RFC8370] recommends that each node establish Node-ID hello sessions with all its immediate neighbors. Non-immediate PLR or MP failure is detected from the state of remote signaling adjacency established according to Section 4.2.2 of this document.¶
When a router detects the Phop link or the Phop node failure for an LSP and the router is not an MP for the LSP, then it MUST send a Conditional PathTear (refer to Section 4.4 of this document) and delete the PSB and RSB states corresponding to the LSP.¶
When the Phop link for an LSP fails on a router that is an LP-MP for the LSP, the LP-MP MUST retain the PSB and RSB states corresponding to the LSP till the occurrence of any of the following events.¶
When a router that is an LP-MP for an LSP detects Phop node failure from the Node-ID signaling adjacency state, the LP-MP MUST send a normal PathTear and delete the PSB and RSB states corresponding to the LSP.¶
When a router that is an NP-MP for an LSP detects Phop link failure, or Phop node failure from the Node-ID signaling adjacency, the router MUST retain the PSB and RSB states corresponding to the LSP till the occurrence of any of the following events.¶
When a router that is an NP-MP for an LSP did not detect the Phop link or the Phop node failure, but receives a Conditional PathTear from the Phop node, then the router MUST retain the PSB and RSB states corresponding to the LSP till the occurrence of any of the following events.¶
Receiving a Conditional PathTear from the Phop node will not impact the "remote" state from the PPhop PLR. Note that the Phop node must have sent the Conditional PathTear as it was not an MP for the LSP (see Section 4.3.1 of this document).¶
In the example topology Figure 1, we assume C & D are the NP-MPs for the PLRs A & B respectively. Now when A-B link fails, as B is not an MP and its Phop link has failed, B will delete the LSP state (this behavior is required for unprotected LSPs - refer to Section 4.3.1 of this document). In the data plane, that would require B to delete the label forwarding entry corresponding to the LSP. So if B's downstream nodes C and D continue to retain state, it would not be correct for D to continue to assume itself as the NP-MP for the PLR B.¶
The mechanism that enables D to stop considering itself as the NP-MP for B and delete the corresponding "remote" path state is given below.¶
A router may simultaneously be the LP-MP as well as the NP-MP for the Phop and the PPhop nodes respectively of an LSP. If the Phop link fails on such a node, the node MUST retain the PSB and RSB states corresponding to the LSP till the occurrence of any of the following events.¶
If a router that is both an LP-MP and an NP-MP detects Phop node failure, then the node MUST retain the PSB and RSB states corresponding to the LSP till the occurrence of any of the following events.¶
In the example provided in Section 4.3.3 of this document, B deletes the PSB and RSB states corresponding to the LSP once B detects its Phop link went down as B is not an MP. If B were to send a PathTear normally, then C would delete LSP state immediately. In order to avoid this, there should be some mechanism by which B can indicate to C that B does not require the receiving node to unconditionally delete the LSP state immediately. For this, B MUST add a new optional CONDITIONS object in the PathTear. The CONDITIONS object is defined in Section 4.4.3 of this document. If node C also understands the new object, then C MUST NOT delete the LSP state if it is an NP-MP.¶
A router that is not an MP for an LSP MUST delete the PSB and RSB states corresponding to the LSP if the Phop link or the Phop Node-ID signaling adjacency goes down (see Section 4.3.1 of this document). The router MUST send a Conditional PathTear if the following are also true.¶
When a router that is not an NP-MP receives a Conditional PathTear, the node MUST delete the PSB and RSB states corresponding to the LSP, and process the Conditional PathTear by considering it as a normal PathTear. Specifically, the node MUST NOT propagate the Conditional PathTear downstream but remove the optional object and send a normal PathTear downstream.¶
When a node that is an NP-MP receives a Conditional PathTear, it MUST NOT delete LSP state. The node MUST check whether the Phop node had previously included the B-SFRR-Ready Extended Association object in the Path. If the object had been included previously by the Phop, then the node processing the Conditional PathTear from the Phop MUST remove the corresponding object and trigger a Path downstream.¶
If a Conditional PathTear is received from a neighbor that has not advertised support (refer to Section 4.6 of this document) for the new procedures defined in this document, then the node MUST consider the message as a normal PathTear. The node MUST propagate the normal PathTear downstream and delete the LSP state.¶
As any implementation that does not support Conditional PathTear MUST ignore the new object but process the message as a normal PathTear without generating any error, the Class-Num of the new object MUST be 10bbbbbb where 'b' represents a bit (from Section 3.10 of [RFC2205]).¶
The new object is called as "CONDITIONS" object that will specify the conditions under which default processing rules of the RSVP-TE message MUST be invoked.¶
The object has the following format:¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class | C-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: This contains the size of the object in bytes and should be set to eight.
Class: To be assigned
C-type: 1
Merge-point condition (M) bit: If the M bit is set to 1, then the
PathTear message MUST be processed according to the receiver router
role, i.e. if the receiving router is an MP or not for the LSP.
If the M-bit is set to 0, then the PathTear message MUST be processed
as a normal PathTear message for the LSP.¶
If the ingress wants to tear down the LSP because of a management event while the LSP is being locally repaired at a transit PLR, it would not be desirable to wait till the completion of backup LSP signaling to perform state cleanup. To enable LSP state cleanup when the LSP is being locally repaired, the PLR MUST send a "Remote" PathTear message instructing the MP to delete the PSB and RSB states corresponding to the LSP. The TTL in the "Remote" PathTear message MUST be set to 255.¶
Let us consider that node C in the example topology (Figure 1) has gone down and node B locally repairs the LSP.¶
If local repair fails on the PLR after a failure, then this MUST be considered as a case for cleaning up LSP state from the PLR to the Egress. The PLR achieves state cleanup by sending "Remote" PathTear to the MP. The MP MUST delete the states corresponding to the LSP also propagate the PathTear downstream thereby achieving state cleanup from all downstream nodes up to the LSP egress. Note that in the case of link protection, the PathTear MUST be directed to the LP-MP's Node-ID IP address rather than the Nhop interface address.¶
When a PLR router that has already made NP available for an LSP detects a change in the RRO carried in the Resv message that indicates that the router's former NP-MP is no longer present on the path of the LSP, then the router MUST send a "Remote" PathTear directly to its former NP-MP.¶
In the example topology Figure 1, let us assume A has made node protection available for an LSP and C has concluded it is the NP-MP for PLR A. When the B-C link fails then C, implementing the procedure specified in Section 4.3.4 of this document, will retain the states corresponding to the LSP until: the remote Node-ID signaling adjacency with A goes down, or a PathTear or a ResvTear is received for its PSB or RSB respectively. If B also has made node protection available, B will eventually complete backup LSP signaling with its NP-MP D and trigger a Resv to A with RRO changed. The new RRO of the LSP carried in the Resv will not contain C. When A processes the Resv message with a new RRO not containing C - its former NP-MP, A MUST send a "Remote" PathTear to C. When C receives the "Remote" PathTear for its PSB state, C will send a normal PathTear downstream to D and delete both the PSB and RSB states corresponding to the LSP. As D has already received backup LSP signaling from B, D will retain control plane and forwarding states corresponding to the LSP.¶
If an LSP is preempted on an LP-MP after its Phop or the incoming link has already failed but the backup LSP has not been signaled yet as part of local repair procedure, then the node MUST send a normal PathTear and delete both the PSB and RSB states corresponding to the LSP. As the LP-MP has retained the LSP state expecting the PLR to initiate backup LSP signaling, preemption would bring down the LSP and the node would not be LP-MP any more requiring the node to clean up the LSP state.¶
If an LSP is preempted on an NP-MP after its Phop link has already failed but the backup LSP has not been signaled yet, then the node MUST send a normal PathTear and delete the PSB and RSB states corresponding to the LSP. As the NP-MP has retained LSP state expecting the PLR to initiate backup LSP signaling, preemption would bring down the LSP and the node would not be NP-MP any more requiring the node to clean up LSP state.¶
Let us consider that B-C link goes down on the same example topology (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP state.¶
"Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set of procedures defined in this document to eliminate the reliance of periodic refreshes. The extensions proposed in RSVP-TE Summary FRR [RFC8796] may apply to implementations that do not support RI-RSVP-FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state cleanup namely Conditional and "Remote" PathTear require support from one-hop and two-hop neighboring nodes along the LSP path. So procedures that fall under LSP state cleanup category MUST NOT be turned on if any of the nodes involved in the node protection FRR i.e. the PLR, the MP and the intermediate node in the case of NP, DOES NOT support RI-RSVP-FRR extensions. Note that for LSPs requesting link protection, only the PLR and the LP-MP MUST support the extensions.¶
An implementation supporting RI-RSVP-FRR extensions SHOULD set the flag "Refresh interval Independent RSVP" or RI-RSVP flag in the CAPABILITY object carried in Hello messages as specified in RSVP-TE Scaling Techniques [RFC8370]. If an implementation does not set the flag even if it supports RI-RSVP-FRR extensions, then its neighbors will view the node as any node that does not support the extensions.¶
Every node that supports RI-RSVP-FRR MUST support the procedures defined in this section in order to support backward compatibility for those subset of LSPs that also traverse nodes that do not support RI-RSVP-FRR.¶
The procedures on the downstream direction are as follows.¶
If a node reduces the refresh time using the above procedures, it MUST NOT send any "Remote" PathTear or Conditional PathTear message to the downstream node.¶
Consider the example topology in Figure 1. If C does not support the RI-RSVP-FRR extensions, then:¶
The procedures are as follows.¶
If a node supporting facility backup protection [RFC4090] sets the RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR extensions, then it leaves room for stale state to linger around for an inordinate period of time or disruption of normal FRR operation (see Section 3 of this document). Consider the example topology Figure 1 provided in this document.¶
The backward compatibility procedures described in the previous sub-sections imply that a router supporting the RI-RSVP-FRR extensions specified in this document can apply the procedures specified in the document either in the downstream or upstream direction of an LSP, depending on the capability of the routers downstream or upstream in the LSP path.¶
For example, if an implementation supporting the RI-RSVP-FRR extensions specified in this document is deployed on all routers in particular region of the network and if all the LSPs in the network request node protection, then the FRR extensions will only be applied for the LSP segments that traverse the particular region. This will aid incremental deployment of these extensions and also allow reaping the benefits of the extensions in portions of the network where it is supported.¶
The security considerations pertaining to [RFC2961], [RFC4090], [RFC8370], [RFC8796] and [RFC5920] remain relevant. When using RSVP Cryptographic Authentication [RFC2747], more robust algorithms [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed message digest where possible.¶
This document extends the applicability of Node-ID based Hello session between immediate neighbors. The Node-ID based Hello session between the PLR and the NP-MP may require the two routers to exchange Hello messages with non-immediate neighbor. So, the implementations SHOULD provide the option to configure Node-ID neighbor specific or global authentication key to authentication messages received from Node-ID neighbors. The network administrator SHOULD utilize this option to enable RSVP-TE routers to authenticate Node-ID Hello messages received with TTL greater than 1. Implementations SHOULD also provide the option to specify a limit on the number of Node-ID based Hello sessions that can be established on a router supporting the extensions defined in this document.¶
RSVP Change Guidelines [RFC3936] defines the Class-Number name space for RSVP objects. The name space is managed by IANA.¶
IANA registry: RSVP Parameters
Subsection: Class Names, Class Numbers, and Class Types¶
A new RSVP object using a Class-Number from 128-183 range called the "CONDITIONS" object is defined in Section 4.4 of this document. The Class-Number from 128-183 range will be allocated by IANA.¶
Apart from allocating Class-Number for the CONDITIONS object, the allocation of the Merge-point condition bit or M-bit (see Section 4.4 of this document) will also be done by IANA.¶
Flag: 0x1 Name: Merge-point condition bit or M-bit¶
We are very grateful to Yakov Rekhter for his contributions to the development of the idea and thorough review of content of the draft. We are thankful to Raveendra Torvi and Yimin Shen for their comments and inputs on early versions of the draft. We also thank Alexander Okonnikov for his review and comments on the draft.¶
Markus Jork
Juniper Networks, Inc.
Email: mjork@juniper.net¶
Harish Sitaraman
Individual Contributor
Email: harish.ietf@gmail.com¶
Vishnu Pavan Beeram
Juniper Networks, Inc.
Email: vbeeram@juniper.net¶
Ebben Aries
Juniper Networks, Inc.
Email: exa@juniper.com¶
Mike Taillon
Cisco Systems, Inc.
Email: mtaillon@cisco.com¶