Internet-Draft | BGP CT - SRv6 Adaptation | January 2024 |
Vairavakkalai & Venkataraman | Expires 31 July 2024 | [Page] |
This document specifies how the mechanisms for "Intent Driven Service Mapping" defined in [BGP-CT] are applied to SRv6 dataplane. The extensions needed for SRv6 dataplane operations are specified. Base procedures of BGP CT are followed unaltered.¶
Illustration of how BGP CT procedures work in SRv6 dataplane is provided in this document.¶
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 RFC 2119 [RFC2119] RFC 8174 [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 31 July 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.¶
This document specifies how the mechanisms for "Intent Driven Service Mapping" defined in [BGP-CT] are applied to SRv6 dataplane. The extensions needed for SRv6 dataplane operations are specified. Base procedures of BGP CT are followed unaltered.¶
The BGP CT family (e.g. AFI/SAFI 2/76) is used to set up inter-domain tunnels satisfying a certain Transport Class, when using Segment Routing over IPv6 (SRv6) data plane on the inter-AS links or as an intra-AS tunneling mechanism. Illustration of how BGP CT procedures work in these scenarios is provided in this document.¶
AS: Autonomous System¶
NLRI: Network Layer Reachability Information¶
TC: Transport Class¶
TC ID: Transport Class Identifier¶
AFI: Address Family Identifier¶
SAFI: Subsequent Address Family Identifier¶
SN: Service Node¶
BN: Border Node¶
PE: Provider Edge¶
BGP CT: BGP Classful Transport family (AFI/SAFIs 1/76, 2/76)¶
RT: Route Target extended community¶
RD: Route Distinguisher¶
VRF: Virtual Router Forwarding Table¶
SR: Segment Routing¶
SRTE: Segment Routing Traffic Engineering¶
SID: SR Segment Identifier¶
EP: Endpoint, e.g. a loopback address in the network¶
SLA: Service Level Agreement¶
MPLS: Multi Protocol Label Switching¶
Intent: A set of operational goals (that a network should meet) and outcomes (that a network is supposed to deliver) defined in a declarative manner without specifying how to achieve or implement them, as defined in Section 2 of [RFC9315].¶
Service Family: A BGP address family used for advertising routes for "data traffic" as opposed to tunnels (e.g. AFI/SAFIs 1/1 or 1/128).¶
Transport Family: A BGP address family used for advertising tunnels, which are in turn used by service routes for resolution (e.g. AFI/SAFIs 1/4 or 1/76).¶
Import processing: Receive side processing of an overlay route, including things like import policy application, resolution scheme selection and nexthop resolution.¶
Transport Tunnel : A tunnel over which a service may place traffic. Such a tunnel can be provisioned or signaled using a variety of means (e.g., Generic Routing Encapsulation (GRE), UDP, LDP, RSVP-TE, IGP FLEX-ALGO or SRTE).¶
Tunnel Ingress Route: A Route to Tunnel Destination/Endpoint that is installed at the headend (ingress) of the tunnel using a tunneling mechanism.¶
Tunnel Domain: A domain of the network containing Service Nodes (SNs) and Border Nodes (BNs) under a single administrative control that has tunnels between them. An end-to-end tunnel spanning several adjacent tunnel domains can be created by "stitching" them together using MPLS labels (or an equivalent identifier based on the forwarding architecture).¶
Transport Class: A construct to group transport tunnels offering the same SLA.¶
Transport Class RT: A Route Target Extended Community used to identify a specific Transport Class.¶
Transport Route Database (TRDB): At the SN and BN, a Transport Class has an associated Transport Route Database that collects its tunnel ingress routes.¶
Resolution Scheme: A construct comprising of an ordered set of TRDBs to resolve next hop reachability, for realizing a desired intent.¶
Mapping Community: Any BGP Community/Extended Community on a BGP route that maps to a Resolution Scheme. e.g., color:0:100, transport-target:0:100.¶
Transport Plane: An end-to-end plane consisting of transport tunnels belonging to the same Transport Class. Tunnels of the same Transport Class are stitched together by BGP CT route readvertisements with next hop self to enable Label-Swap forwarding across domain boundaries.¶
The procedures for encoding a BGP Classful Transport (BGP CT) family route are specified in sections 6, section 4 in [BGP-CT]. These are followed, with the addition of SRv6 encapsulation information.¶
A BGP CT node that supports SRv6 forwarding encodes the SID information for SR with respect to SRv6 Data Plane as specified in Section 4.¶
A BGP CT node that does not support MPLS forwarding advertises the special label 3 (Implicit NULL) in the [RFC8277] MPLS Label field. The Implicit NULL label carried in BGP CT route indicates to receiving node that it should not impose any BGP CT label for this route. Thus a pure SRv6 node carries Implicit NULL in the MPLS Label field in RFC8277 BGP CT NLRI.¶
Aspects regarding Interoperability between nodes supporting different forwarding technologies is discussed in Section 6.3, Section 11.3.2 of [BGP-CT].¶
[RFC8986] specifies the SRv6 Endpoint behaviors (End USD, End.B6.Encaps). [SRV6-INTER-DOMAIN] specifies the SRv6 Endpoint behaviors (END.REPLACE, END.REPLACEB6 and END.DB6). These are leveraged for BGP CT routes with SRv6 data plane.¶
The BGP Classful Transport route update for SRv6 MUST include an attribute containing SRv6 SID information, with Transposition scheme disabled.¶
The BGP Classful Transport route update for SRv6 MUST include an attribute containing SRv6 SID information. This may be either the BGP Prefix-SID attribute as specified in [RFC9252] .¶
If the [RFC9252] Prefix-SID attribute also contains a "SRv6 SID Structure Sub-Sub-TLV", the Transposition Length is set to 0 and Transposition Offset is set to 0. This indicates nothing is transposed and that the entire SRv6 SID value is encoded in the "SRv6 SID Information Sub-TLV".¶
It should be noted that prefixes carried in BGP CT family are transport layer end-points, e.g. PE loopback addresses. Thus, the SRv6 SID carried in a BGP CT route is also a transport layer identifier.¶
For an illustration of BGP CT deployment in SRv6 networks, refer following section Section 5 .¶
This section describes BGP CT deployment in SRv6 multi-domain network using Inter-AS Option C architecture.¶
This approach uses stacking of service SRv6 SID over transport SRv6 SID. Transport layer SIDs of types End, End.B6.Encaps defined in [RFC8986], and type END.REPLACE* defined in [SRV6-INTER-DOMAIN] are carried in AFI/SAFI 2/76. Service SID is carried in a service family like AFI/SAFI 2/1 or AFI/SAFI 2/128.¶
In this approach, the number of Service SIDs required at the egress SN is equal to service functions (e.g. Prefix, VRF or Next hop) and the number of Transport SIDs are equal to the number of transport classes.¶
AS1 AS2 ---gold---> ----gold--> CE1---[PE1---P---ASBR1]-----[ASBR2---P---PE2]---CE2 --bronze--> --bronze--> -------Forwarding Direction----->
In the topology shown in Figure 1, there are two AS domains, AS1 and AS2. These are pure IPv6 domains, with no MPLS enabled. Inter-AS links between AS1 and AS2 are also enabled with IPv6 forwarding.¶
Intra-AS nodes in AS1 and AS2 speak IBGP CT (AFI: 2, SAFI: 76) and ISIS-SRv6 between them. The Inter-AS nodes ASBR1, ASBR2 speak EBGP CT (AFI: 2, SAFI:76) between them. Transport Classes Gold (100) and Bronze (200) are provisioned in all PEs and ASBRs. All BGP CT advertisements in this example carry a MPLS label value of 3 (Implicit NULL) in the NLRI encoding.¶
Reachability between PE1 and PE2 is formed using BGP CT family. Service families like IPv4 unicast (AFI: 1, SAFI: 1) and L3VPN (AFI: 2, SAFI: 128) is negotiated on multihop EBGP session between PE1 and PE2. These service routes carry service SID to identify service functions at the advertising PE, and mapping community to identify the desired Intent.¶
The following SRv6 locators are provisioned:¶
PE2-SRv6 : SRv6 Locator for PE2 best effort transport class¶
PE2-SRv6-gold-loc : SRv6 Locator for PE2 gold transport class¶
PE2-SRv6-bronze-loc : SRv6 Locator for PE2 bronze transport class¶
ASBR1-SRv6-loc : SRv6 Locator for ASBR1 best effort transport class¶
ASBR1-SRv6-gold-loc : SRv6 Locator for ASBR1 gold transport class¶
ASBR1-SRv6-bronze-loc : SRv6 Locator for ASBR1 bronze transport class¶
ASBR2-SRv6-loc : SRv6 Locator for ASBR2 best effort transport class¶
ASBR2-SRv6-gold-loc : SRv6 Locator for ASBR2 gold transport class¶
ASBR2-SRv6-bronze-loc : SRv6 Locator for ASBR2 bronze transport class¶
The following transport layer SRv6 End SIDs are provisioned or dynamically allocated on demand:¶
PE2-SRv6-gold : PE2 End SID from PE2-SRv6-gold-loc, for gold transport class.¶
PE2-SRv6-bronze : PE2 End SID from PE2-SRv6-bronze-loc, for bronze transport class.¶
ASBR2-SRv6-PE2-gold-Replace : at ASBR2 End.B6.Encaps SID for PE2, gold transport class.¶
ASBR2-SRv6-PE2-bronze-Replace : at ASBR2 End.B6.Encaps SID for PE2, bronze transport class.¶
ASBR1-SRv6-gold : ASBR1 End SID from ASBR1-SRv6-gold-loc, for gold transport class.¶
ASBR1-SRv6-PE2-gold-Replace : at ASBR1 End.REPLACE SID for PE2, gold transport class.¶
ASBR1-SRv6-bronze : ASBR1 End SID from ASBR1-SRv6-bronze-loc, for bronze transport class.¶
ASBR1-SRv6-PE2-bronze-Replace : at ASBR1 End.REPLACE SID for PE2, bronze transport class.¶
Architecturally, the forwarding semantic of End.REPLACE SID operation is similar to Label SWAP operation in MPLS data plane. When a route received with End SID (e.g. PE2-SRv6-gold or PE2-SRv6-bronze transport SIDs) is readvertised with next hop self, an IPv6 forwarding entry is emitted with a forwarding semantic of End.B6.Encaps operation, which means: Update IPv6 DA with Next Segment in SRH, and Encapsulate SRv6 SID corresponding to the correct transport class. This can be seen in IPv6 FIB of ASBR2 during "BGP CT processing at ASBR2" in the following illustration:¶
The following service layer SRv6 End.DT4 SIDs are provisioned:¶
PE2-SRv6-S1-DT4 : PE2 End.DT4 SID for service S1¶
The locators for the above provisioned SRv6 SIDs will be advertised via ISIS between Intra-AS nodes and the established SRv6 tunnel to the node's loopback will be installed into the corresponding TRDB based on color.¶
The SRv6 tunnel ingress routes are published in the Gold and Bronze TRDBs at ASBR2 as follows:¶
Gold TRDB routes at ASBR2 [ISIS SRv6] PE2-LPBK NH: Encap "Gold-SRv6-Tunnel-to-PE2" tunnel [ISIS SRv6] PE2-SRv6-gold NH: Encap "Gold-SRv6-Tunnel-to-PE2" tunnel Bronze TRDB routes at ASBR2 [ISIS SRv6] PE2-LPBK NH: Encap "Bronze-SRv6-Tunnel-to-PE2" tunnel [ISIS SRv6] PE2-SRv6-bronze: NH: Encap "Bronze-SRv6-Tunnel-to-PE2" tunnel ASBR2: IPv6 FIB for SRv6 [ISIS SRv6] PE2-SRv6-gold, NH: Encap "Gold-SRv6-Tunnel-to-PE2" [ISIS SRv6] PE2-SRv6-bronze, NH: Encap "Bronze-SRv6-Tunnel-to-PE2"¶
The illustrations that follow, show how the BGP CT route for gold transport plane is originated, import processing done and propagated through this network. Similar processing is followed for the bronze transport plane route as well.¶
Firstly, PE2 originates BGP CT route for its transport layer endpoints like Loopback address with SRv6 SID information to ASBR2 as follows:¶
IBGP CT routes from PE2 to ASBR2 RD1:PE2-LPBK, transport-target:0:100, Prefix-SID: PE2-SRv6-gold NH: PE2-LPBK RD2:PE2-LPBK, transport-target:0:200, Prefix-SID: PE2-SRv6-bronze NH: PE2-LPBK PE2: IPv6 FIB for SRv6 [BGP CT] PE2-SRv6-S1-DT4 NH: Decap, Perform service S1¶
When ASBR2 receives the IBGP CT advertisement for gold route from PE2, it performs import processing and next hop resolution for the endpoint PE2-LPBK in the gold TRDB based on its transport-target:0:100. This would resolve over the ISIS-SRv6 route in gold TRDB and pick "Gold-SRv6-Tunnel-to-PE2" tunnel.¶
On successful resolution, a IPv6 transit route for ASBR2-SRv6-PE2-gold-replace/128 is installed in the global IPv6 FIB with "Gold-SRv6-Tunnel-to-PE2" tunnel as next hop, enabling SRv6 forwarding for gold SLA. The BGP CT routes for RD1:PE2-LPBK is further advertised towards ASBR1 via EBGP CT as follows. During this readvertisement, the next hop is set to self, and SID is rewritten to ASBR2-SRv6-gold-Replace.¶
EBGP CT routes from ASBR2 to ASBR1 RD1:PE2-LPBK, transport-target:0:100, Prefix-SID: ASBR2-SRv6-PE2-gold-Replace, NH: ASBR2_InterAS_Link RD2:PE2-LPBK, transport-target:0:200, Prefix-SID: ASBR2-SRv6-PE2-bronze-Replace, NH: ASBR2_InterAS_Link ASBR2: IPv6 FIB for SRv6 [BGP CT] ASBR2-SRv6-PE2-gold-Replace NH: UpdateIPv6DA(SRH.NextSegment), Encap "Gold-SRv6-Tunnel-to-PE2" [BGP CT] ASBR2-SRv6-PE2-bronze-Replace NH: UpdateIPv6DA(SRH.NextSegment), Encap "Bronze-SRv6-Tunnel-to-PE2"¶
When ASBR1 receives this EBGP CT advertisement from ASBR2, an IPv6 route for ASBR1-SRv6-gold-Replace/128 is installed with a next hop of ASBR1_InterAS_Link in the global IPv6 FIB, enabling SRv6 forwarding for gold SLA. The BGP CT route for RD1:PE2-LPBK is further advertised to PE1 via IBGP CT, with next hop set to self, and SID rewritten to ASBR1-SRv6-gold-Replace.¶
IBGP CT routes from ASBR1 to PE1 RD1:PE2-LPBK, transport-target:0:100, Prefix-SID: ASBR1-SRv6-PE2-gold-Replace, NH: ASBR1-LPBK RD2:PE2-LPBK, transport-target:0:200, Prefix-SID: ASBR1-SRv6-PE2-bronze-Replace, NH: ASBR1-LPBK ASBR1: IPv6 FIB for SRv6 [BGP CT] ASBR1-SRv6-PE2-gold-Replace, NH: ASBR2_InterAS_Link SID op: ReplaceSID(ASBR2-SRv6-PE2-gold-Replace) [BGP CT] ASBR1-SRv6-PE2-bronze-Replace, NH: ASBR2_InterAS_Link SID op: ReplaceSID(ASBR2-SRv6-PE2-bronze-Replace)¶
When PE1 receives this IBGP CT advertisement from ASBR1, it resolves the next hop ASBR1-LPBK in the gold TRDB based on its transport-target:0:100. This would resolve over the ISIS-SRv6 route in gold TRDB and pick "Gold-SRv6-Tunnel-to-ASBR1".¶
This forms the end-to-end Gold SLA path from PE1 to PE2. The gold BGP CT route for PE2-LPBK is installed in gold TRDB, and can be used for resolving service route next hops. The Transport layer SIDs are replaced at each border node, which reduces the number of SID decaps required at the egress PE.¶
Gold TRDB routes at PE1 [BGP CT] PE2-LPBK, NH: ASBR1-SRv6-gold SID op: EncapSID(ASBR1-SRv6-PE2-gold-Replace) Bronze TRDB routes at PE1 [BGP CT] PE2-LPBK, NH: ASBR1-SRv6-bronze SID op: EncapSID(ASBR1-SRv6-PE2-bronze-Replace) PE1: IPv6 FIB for SRv6 [BGP CT] PE2-LPBK, NH: ASBR1-SRv6-gold SID op: EncapSID(ASBR1-SRv6-PE2-gold-Replace) [BGP CT] PE2-LPBK, NH: ASBR1-SRv6-bronze SID op: EncapSID(ASBR1-SRv6-PE2-bronze-Replace) [ISIS SRv6] ASBR1-SRv6-gold, NH: Encap "Gold-SRv6-Tunnel-to-ASBR1" [ISIS SRv6] ASBR1-SRv6-bronze, NH: Encap "Bronze-SRv6-Tunnel-to-ASBR1"¶
Furthermore, any service routes received with next hop as PE2-LPBK and Mapping Community as Color:0:100 indicating Gold SLA will use the Resolution Scheme associated with its Mapping Community to resolve over the PE2-LPBK CT route installed in the gold TRDB, and push the SRv6-gold SID stack to reach PE2.¶
Similarly, any service routes received with next hop as PE2-LPBK and Mapping Community as Color:0:200 indicating Bronze SLA will use the Resolution Scheme associated with its Mapping Community to resolve over the PE2-LPBK CT route installed in the bronze TRDB, and push the SRv6-bronze SID stack to reach PE2. This is shown as follows:¶
BGP Service routes advertisement from PE2 to PE1: SVC_PFX1, color:0:100, Prefix-SID: PE2-SRv6-S1-DT4, NH: PE2-LPBK SVC_PFX2, color:0:200, Prefix-SID: PE2-SRv6-S1-DT4, NH: PE2-LPBK PE1: Service routes FIB [BGP INET] SVC_PFX1, color:0:100 NH: EncapSID "PE2-SRv6-S1-DT4, ASBR1-SRv6-gold-Repace, Gold-SRv6-Tunnel-to-ASBR1(outer)" [BGP INET] SVC_PFX2, color:0:200 NH: EncapSID "PE2-SRv6-S1-DT4, ASBR1-SRv6-bronze-Replace, Bronze-SRv6-Tunnel-to-ASBR1(outer)"¶
The operational, scaling and convergence aspects of this approach are similar to the aspects of applying BGP CT procedures to the MPLS data plane.¶
CPR is defined in the document: Colorful Prefix Routing for SRv6 based services [Colorful-Prefix-Routing-SRv6], and uses IPv6 Unicast (AFI/SAFI = 2/1) as a transport family. CPR mechanism does not use BGP CT (AFI/SAFI 2/76) address family.¶
CPR uses color encoded SRv6 service SIDs to determine the intent-aware transport paths for the service, without a separate transport SRv6 SID. It routes using "Colorful Prefix" locators in the transport layer, which are carried in the IPv6 Unicast BGP family.¶
A Next hop Resolution Scheme similar to that of BGP CT [BGP-CT] is used on IPv6 Unicast family to resolve “Colorful Prefix” locator routes that carry a mapping community to intent-aware paths in each domain.¶
By virtue of the CPR SID allocation scheme, the service SIDs inherit the Intent of the corresponding Colorful Prefix route just by performing longest prefix match in forwarding plane.¶
AS1 AS2 ---gold---> ----gold--> CE1---[PE1---P---ASBR1]-----[ASBR2---P---PE2]---CE2 --bronze--> --bronze--> Colored SRv6 Locators: Gold, Bronze Colored Service SIDs: Gold-SID-1, Bronze-SID-1 Transport Family: IPv6 + Mapping Community (Color) Resolution Scheme: IPv6 Locator resolution over Intra Domain SRv6 Tunnel in IPv6 RIB using Mapping Community (color) Forwarding Lookup: Longest Prefix Match Gold: SID Gold-SID-1 LPM to Locator Gold Bronze: SID Gold-SID-1 LPM to Locator Bronze ------------IPv6-Forwarding--------->
The CPR approach can be used to support intent driven routing while minimizing SRv6 encapsulation overhead, at the cost of careful SID numbering and planning. The state in the transport network is a function of total number of Colorful Prefixes.¶
In the CPR approach, typically one service SID is allocated for each service function (e.g. VRF) which is associated with a specific intent. In some special scenarios, for example, when different service routes in the same VRF are with different intents, a unique service SID would need to be allocated for each intent associated with the VRF.¶
However, the CPR mechanism preserves BGP PIC (Prefix scale Independent Convergence) for the egress SN failure scenario where only Colorful Prefix routes need to be withdrawn.¶
CPR achieves strict Intent based forwarding for the service routes. Fallback to best effort transport class is achieved by numbering all SRv6 Colorful Prefix locators at the egress SN to fall in the same subnet as the SRv6 locator that uses best effort transport class. Customized intent fallback between different color transport classes may be achieved by allocating a CPR prefix for each such intent fallback policy, and advertising that CPR prefix with an appropriate mapping community, that maps to a customized resolution scheme. Alternatively, the intent fallback policy may be provisioned on the ingress nodes directly.¶
Furthermore, IPv6 Unicast family is widely deployed to carry Internet Service routes. Repurposing IPv6 Unicast family to carry Transport routes also may impact the operational complexity and security aspects in the network.¶
This document follows error handling procedures defined in [BGP-CT], and extends it further.¶
If a BGP CT route is received with a [RFC9252] BGP Prefix-SID attribute containing a "SRv6 SID Information Sub-TLV", and also contains a "SRv6 SID Structure Sub-Sub-TLV", the Transposition Length is not set to 0 or Transposition Offset is not set to 0. This indicates transposition is in use, which is not expected on BGP CT route. Treat-as-withdraw approach from [RFC7606] is used to handle this error. The route is kept as Unusable, with appropriate diagnostic information, to aid troubleshooting.¶
If a BGP speaker considers a received BGP CT route invalid for some reason, but is able to successfully parse the NLRI and attributes, Treat-as-withdraw approach from [RFC7606] is used. The route is kept as Unusable, with appropriate diagnostic information, to aid troubleshooting.¶
This document makes no new requests of IANA.¶
This document does not change the underlying security issues inherent in the existing BGP protocol, such as those described in [RFC4271] and [RFC4272].¶
This document follows the security considerations described in [BGP-CT]. As mentioned there, the "Walled Garden" approach is followed to carry routes for loopback addresses in BGP CT family (AFI/SAFI: 1/76 or 2/76). Thus mitigating the risk of unintended route escapes.¶
BGP CT routes distribute SRv6 SIDs for SRv6 dataplanes and hence security considerations of Section 9.3 of [RFC9252] apply. Moreover, SRv6 SID transposition scheme is disabled in BGP CT, as described in Section 4, to mitigate the risk of misinterpreting transposed SRv6 SID information as an MPLS label.¶
As [RFC4272] discusses, BGP is vulnerable to traffic-diversion attacks. This SAFI routes adds a new means by which an attacker could cause the traffic to be diverted from its normal path. Potential consequences include "hijacking" of traffic (insertion of an undesired node in the path, which allows for inspection or modification of traffic, or avoidance of security controls) or denial of service (directing traffic to a node that doesn't desire to receive it).¶
In order to mitigate the risk of the diversion of traffic from its intended destination, existing BGPsec solution could be extended and supported for this SAFI. The restriction of the applicability of this SAFI to its intended well-defined scope limits the likelihood of traffic diversions. Furthermore, as long as the filtering and appropriate configuration mechanisms discussed previously are applied diligently, risk of the diversion of the traffic is eliminated.¶
The authors thank Jeff Haas, John Scudder, Susan Hares, Dongjie (Jimmy), Moses Nagarajah, Jeffrey (Zhaohui) Zhang, Joel Harpern, Jingrong Xie, Mohamed Boucadair, Greg Skinner, Simon Leinen, Navaneetha Krishnan, Ravi M R, Chandrasekar Ramachandran, Shradha Hegde, Colby Barth, Vishnu Pavan Beeram, Sunil Malali, William J Britto, R Shilpa, Ashish Kumar (FE), Sunil Kumar Rawat, Abhishek Chakraborty, Richard Roberts, Krzysztof Szarkowicz, John E Drake, Srihari Sangli, Jim Uttaro, Luay Jalil, Keyur Patel, Ketan Talaulikar, Dhananjaya Rao, Swadesh Agarwal, Robert Raszuk, Ahmed Darwish, Aravind Srinivas Srinivasa Prabhakar, Moshiko Nayman, Chris Tripp, Gyan Mishra, Vijay Kestur, Santosh Kolenchery for all the valuable discussions, constructive criticisms, and review comments.¶
The decision to not reuse SAFI 128 and create a new address-family to carry these transport-routes was based on suggestion made by Richard Roberts and Krzysztof Szarkowicz.¶