Internet-Draft | BGP extensions for SRv6 and MPLS interwo | July 2024 |
Agrawal, et al. | Expires 24 January 2025 | [Page] |
This document define the BGP protocol extensions required to provide interworking between SRv6 and SR-MPLS/MPLS for SRv6 deployment.¶
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 24 January 2025.¶
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.¶
The deployment of SRv6 into existing networks require SRv6 to interwork with SR-MPLS/MPLS. Draft [I-D.agrawal-spring-srv6-mpls-interworking] describes SRv6 and MPLS interworking architecture in multi domain network where each domain run SRv6 or MPLS data plane independently. Specifically section 7.1.2 of draft details BGP inter-domain routing procedures to advertise PE locators or PE loopbacks address across such network with next hop self at domain border routers. When performing next hop self on domain border router and further propagation, draft proposes to allocate and signal additional upstream data plane specific information. This document extract the BGP protocol extensions proposed in [I-D.agrawal-spring-srv6-mpls-interworking] to signal SRv6 SID with BGP SAFI 4 or SAFI 1 advertisements. This is done to independently state BGP protocol extensions and future applicability of them for other use cases.¶
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.¶
[RFC9252] extended BGP Prefix SID Attribute (PFA) to signal SRv6 SID in "SRv6 L3 Service" and "SRv6 L2 Service" TLVs for layer 3 and layer 2 services. This document introduces new "SRv6 tunnel for label route" TLV for safi 4 [RFC8277] and extends usage of "SRv6 L3 Service" TLV for SAFI 4.¶
[RFC8669] introduced Prefix-SID attribute with TLV type 1 for label index and TLV type 3 for Originator SRGB for AFI=1/2 and SAFI 4 (BGP LU). This document introduces a new TLV called "SRv6 tunnel for label route" of the BGP Prefix-SID Attribute to signal SRv6 SIDs along with MPLS label bound to prefix in NLRI. Behavior that may be encoded but not limited to is End.DTM. "SRv6 tunnel for label route" TLV signals "AND" semantics i.e. push label signaled in NLRI and perform H.Encaps.M with DA as SRv6 SID signaled in TLV. This document limits the usage of this new TLV to AFI=1/2 SAFI 4. The usage of this TLV for other AFI/SAFI is out of scope of this document.¶
"SRv6 tunnel for label route" TLV is encoded exactly like SRv6 Service TLVs in Prefix-SID Attribute [RFC9252] with following modification:¶
TLV Type (1 octet): This field is assigned values from the IANA registry "BGP Prefix-SID TLV Types". It is set to 7 for "SRv6 tunnel for label route" TLV.¶
No transposition scheme is allowed i.e. transposition length MUST be 0 in SRv6 SID Structure Sub-Sub-TLV.¶
Please refer to section 7.1.2.2.1 of [I-D.agrawal-spring-srv6-mpls-interworking] for usage of "SRv6 tunnel for label route" TLV and overall procedures along with control and forwarding state¶
Bound the SRv6 SID of DPM behavior to PE loopback address carried in NLRI of BGP update of SAFI 1 or SAFI 4. Receiving node perform H.Encaps, where destination of IPv6 header is set to SRv6 SID for traffic destined to address in NLRI.¶
Please refer to section 7.1.2.2.2 of [I-D.agrawal-spring-srv6-mpls-interworking] for overall procedures when SRv6 SID is bound to PE address.¶
This document proposes below 2 options to advertise SRv6 SID bound to prefix in NLRI¶
Address in NLRI is only bound to SRv6 SID by advertising node. In this case, SAFI 4 cannot be used to advertise PE loopback across SRv6 domain as label is required in NLRI [RFC8277]. Therefore SRv6 SID with End.DPM behavior bound to prefix in NLRI is advertised in SAFI 1 as per section 5.3 and 5.4 of [RFC9252]. To distinguish from global internet routes on receiver, local policy matching PE loopback addresses or BGP community/extended community attached to such advertisement may be used. Such policy on receiver helps to allocate MPLS label and advertise route further upstream in SAFI 4 in MPLS domain for PE addresses with next hop self. Figure 1 shows BGP update example through SRv6 domain.¶
Advertise MPLS label and SRv6 SID bound to prefix in NLRI. RFC 8669 introduced Prefix-SID attribute with TLV type 1 for label index and TLV type 3 for Originator SRGB for AFI=1/2 and SAFI 4 (BGP LU). This document extends the BGP Prefix-SID attribute [RFC8669] to carry "SRv6 L3 Service TLV" defined in [RFC9252] with AFI=1/2 and SAFI 4. TLV is encoded exactly like SRv6 Service TLVs in Prefix-SID Attribute without transposition. Such an update can be processed by both legacy MPLS ABR and SRv6 capable ABR and use relevant encapsulation. For example, in Figure 2 node 4 being SRv6 capable chooses SRv6 encapsulation and node 44 being legacy continue MPLS encapsulation.¶
A BGP speaker receiving updates with PE address in NLRI and Prefix-SID Attribute with "SRv6 tunnel for label route" TLV or "SRv6 L3 Service" TLV observe the following rules when advertising the route to other peers:¶
If the nexthop is unchanged, the TLVs, including any unrecognized Types of Sub-TLV and Sub-Sub-TLV, SHOULD be propagated further. In addition, all Reserved fields in the TLV or Sub-TLV or Sub-Sub-TLV MUST be propagated unchanged.¶
If the nexthop is modified, the TLV and associated sub-TLVs/Sub-Sub-TLVs SHOULD be updated based on local policy. For example, if upstream is MPLS domain, then TLVs carrying SRv6 SID should be removed and local MPLS label bound to address in NLRI is sent in SAFI 4.¶
This document introduce a new TLV Type of the BGP Prefix-SID attribute. IANA is requested to assign Type value in the registry "BGP Prefix-SID TLV Types" as follows¶
Value Type Reference ---------------------------------------------------------- TBD "SRv6 tunnel for label route" TLV <this document>¶
The authors would like to acknowledge Stephane Litkowski and Ketan Talaulikar for review and comments.¶