Internet DRAFT - draft-ietf-idr-bgp-ct-srv6
draft-ietf-idr-bgp-ct-srv6
Network Working Group K. Vairavakkalai, Ed.
Internet-Draft N. Venkataraman, Ed.
Intended status: Experimental Juniper Networks, Inc.
Expires: 5 September 2024 4 March 2024
BGP CT - Adaptation to SRv6 dataplane
draft-ietf-idr-bgp-ct-srv6-03
Abstract
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.
Requirements Language
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.
Status of This Memo
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 5 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 1]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. NLRI and Nexthop Encoding . . . . . . . . . . . . . . . . . . 5
4. SRv6 Encapsulation Information . . . . . . . . . . . . . . . 5
5. BGP CT deployment in SRv6 networks . . . . . . . . . . . . . 6
5.1. SID stacking approach . . . . . . . . . . . . . . . . . . 6
5.2. Color-encoded Service SID (CPR) Approach . . . . . . . . 14
5.2.1. Analysis of CPR Approach . . . . . . . . . . . . . . 15
6. Error Handling Considerations . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Co-Authors . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Other Contributors . . . . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
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.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 2]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
2. Terminology
AFI: Address Family Identifier
AS: Autonomous System
BGP CT: BGP Classful Transport family (AFI/SAFIs 1/76, 2/76)
BN: Border Node
EP: Endpoint, e.g. a loopback address in the network
MPLS: Multi Protocol Label Switching
NLRI: Network Layer Reachability Information
PE: Provider Edge
RD: Route Distinguisher
RT: Route Target extended community
SAFI: Subsequent Address Family Identifier
SID: SR Segment Identifier
SLA: Service Level Agreement
SN: Service Node
SR: Segment Routing
SRTE: Segment Routing Traffic Engineering
TC: Transport Class
TC ID: Transport Class Identifier
VRF: Virtual Router Forwarding Table
2.1. Definitions
Import processing: Receive side processing of an overlay route,
including things like import policy application, resolution scheme
selection and nexthop resolution.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 3]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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].
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.
Resolution Scheme: A construct comprising of an ordered set of TRDBs
to resolve next hop reachability, for realizing a desired intent.
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).
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 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.
Transport Route Database (TRDB): At the SN and BN, a Transport Class
has an associated Transport Route Database that collects its tunnel
ingress routes.
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 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).
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 4]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
Tunnel Ingress Route: A Route to Tunnel Destination/Endpoint that is
installed at the headend (ingress) of the tunnel using a tunneling
mechanism.
3. NLRI and Nexthop Encoding
The procedures for encoding a BGP Classful Transport (BGP CT) family
route are specified in sections 4,5,6 and 7 of [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 and
Section 11.3.2 of [BGP-CT].
4. SRv6 Encapsulation Information
[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. The BGP Prefix-SID
attribute as specified in [RFC9252] is used to carry this information
correctly.
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".
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 5]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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 .
5. BGP CT deployment in SRv6 networks
This section describes BGP CT deployment in SRv6 multi-domain network
using Inter-AS Option C architecture.
5.1. SID stacking approach
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----->
Figure 1: BGP CT in SRv6 Only Data plane
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.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 6]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 7]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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:
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 8]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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 below, shows the following BGP CT operations for
the gold plane.
- BGP CT route origination
- Import processing for the route, and
- BGP CT route propagation
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:
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 9]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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 are advertised further
towards ASBR1 via EBGP CT. During this readvertisement, the next hop
is set to self, and SID is rewritten to ASBR2-SRv6-gold-Replace. The
following illustration captures the advertisements from ASBR2 to
ASBR1 as well as the IPv6 FIB in ASBR2.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 10]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 11]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 12]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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"
Service routes that are 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:
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 13]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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-Replace,
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.
5.2. Color-encoded Service SID (CPR) Approach
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.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 14]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
AS1 AS2
---gold---> ----gold-->
CE1---[PE1---P---ASBR1]-----[ASBR2---P---PE2]---CE2
--bronze--> --bronze-->
------------IPv6-Forwarding--------->
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
Figure 2: CT Interactions for CPR apprach
5.2.1. Analysis of CPR Approach
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.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 15]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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.
6. Error Handling Considerations
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.
7. IANA Considerations
This document makes no new requests of IANA.
8. Security Considerations
This document does not change the underlying security issues inherent
in the existing BGP protocol, such as those described in [RFC4271]
and [RFC4272].
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 16]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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.
9. References
9.1. Normative References
[BGP-CT] Vairavakkalai, Ed. and Venkataraman, Ed., "BGP Classful
Transport Planes", 22 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
ct-16>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 17]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
[SRV6-INTER-DOMAIN]
K A, Ed., "SRv6 inter-domain mapping SIDs", 29 January
2024, <https://datatracker.ietf.org/doc/html/draft-salih-
spring-srv6-inter-domain-sids-04>.
9.2. Informative References
[Colorful-Prefix-Routing-SRv6]
Wang, Ed., "BGP Colorful Prefix Routing for SRv6 based
Services", 18 December 2023,
<https://www.ietf.org/archive/id/draft-ietf-idr-cpr-
00.html>.
[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
Tantsura, "Intent-Based Networking - Concepts and
Definitions", RFC 9315, DOI 10.17487/RFC9315, October
2022, <https://www.rfc-editor.org/info/rfc9315>.
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 18]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
Contributors
Co-Authors
Reshma Das
Juniper Networks, Inc.
1133 Innovation Way,
Sunnyvale, CA 94089
United States of America
Email: dreshma@juniper.net
Israel Means
AT&T
2212 Avenida Mara,
Chula Vista, California 91914
United States of America
Email: israel.means@att.com
Csaba Mate
KIFU, Hungarian NREN
Budapest
35 Vaci street,
1134
Hungary
Email: ietf@nop.hu
Deepak J Gowda
Extreme Networks
55 Commerce Valley Drive West, Suite 300,
Thornhill, Toronto, Ontario L3T 7V9
Canada
Email: dgowda@extremenetworks.com
Other Contributors
Balaji Rajagopalan
Juniper Networks, Inc.
Electra, Exora Business Park~Marathahalli - Sarjapur Outer Ring Road,
Bangalore 560103
KA
India
Email: balajir@juniper.net
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 19]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
Rajesh M
Juniper Networks, Inc.
Electra, Exora Business Park~Marathahalli - Sarjapur Outer Ring Road,
Bangalore 560103
KA
India
Email: mrajesh@juniper.net
Chaitanya Yadlapalli
AT&T
200 S Laurel Ave,
Middletown,, NJ 07748
United States of America
Email: cy098d@att.com
Mazen Khaddam
Cox Communications Inc.
Atlanta, GA
United States of America
Email: mazen.khaddam@cox.com
Rafal Jan Szarecki
Google.
1160 N Mathilda Ave, Bldg 5,
Sunnyvale,, CA 94089
United States of America
Email: szarecki@google.com
Xiaohu Xu
China Mobile
Beijing
China
Email: xuxiaohu@cmss.chinamobile.com
Acknowledgements
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,
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 20]
Internet-Draft BGP CT - SRv6 Adaptation March 2024
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.
Authors' Addresses
Kaliraj Vairavakkalai (editor)
Juniper Networks, Inc.
1133 Innovation Way,
Sunnyvale, CA 94089
United States of America
Email: kaliraj@juniper.net
Natrajan Venkataraman (editor)
Juniper Networks, Inc.
1133 Innovation Way,
Sunnyvale, CA 94089
United States of America
Email: natv@juniper.net
Vairavakkalai & VenkatarExpires 5 September 2024 [Page 21]
