| Internet-Draft | SRv6-based BGP Service Capability | October 2024 |
| Liu, et al. | Expires 11 April 2025 | [Page] |
[RFC9252] specifies that implementations MUST provide a mechanism to control advertisement of SRv6-based BGP service routes on a per neighbor and per service basis. This document provides analysis on the problems that may be encountered if the SRv6-based service routes are received by the MPLS-only PEs. Some currently used SRv6-based service routes advertisement controlling methods by configuration or network planning are also described. And this document proposes an automatic advertisement controlling method for SRv6-based service routes by defining a new Capability Code for SRv6-based BGP service capability.¶
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 11 April 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.¶
[RFC9252] defines procedures and messages for SRv6-based services. When an egress PE is enabled for BGP Services over SRv6 data plane, it signals one or more SRv6 Service SIDs enclosed in SRv6 Service TLV(s) within the BGP Prefix-SID Attribute[RFC8669] attached to MP-BGP NLRIs. In other words, instead of defining new AFI/SAFIs for SRv6-based service routes, existing AFI/SAFIs of MPLS-based service routes are re-used for SRv6-based service routes.¶
As specified in [RFC9252], there're two options to encode SRv6 service SIDs in the route advertisement:¶
However, [RFC8669] specifies that unknown TLVs in the BGP Prefix attribute MUST be ignored and propagated unmodified. If SRv6-based service routes are received by PEs that are only capable of MPLS-based services, the PEs may discard SRv6 Services TLV in the BGP Prefix attribute and process these routes wrongly, which may leads to service failure and/or abnormal extra traffic flows in the network.¶
To avoid these problems, [RFC9252] specifies that implementations MUST provide a mechanism to control advertisement of SRv6-based BGP service routes on a per neighbor and per service basis.¶
This document provides analysis on the problems that may be encountered in the MPLS and SRv6 co-existence scenario if the SRv6-based service routes are received by the MPLS-only PEs. Some currently used SRv6-based service routes advertisement controlling methods by configuration or network planning are also described. And this document proposes an automatic advertisement controlling method for SRv6-based service routes by defining a new Capability Code [RFC5492] for SRv6-based BGP service capability.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
In the progress of network upgrading, some of the legacy devices that only support MPLS/SR-MPLS will coexist with the new devices capable of SRv6 for a long time.¶
+-----+
................|S-RR |..................
: +-----+ :
: :
: :
: :
: :
: +----------------+ :
: | |-------PE2...:
PE1-------| Backbone | :
| |-------PE3...:
+----------------+
As shown in Figure 1, PE1 is a legacy device that only supports MPLS-based services, PE2 supports both MPLS-based and SRv6-based services, and PE3 is an SRv6-only device. S-RR is a service route reflector that supports both MPLS and SRv6. On PE2, a SRv6 service SID sid-1 and a MPLS VPN route label label-1 are assigned for overlay service 1. On PE3, only SRv6-based service is enabled and configured for overlap service 2.¶
On PE2,the SRv6 service SID and a MPLS VPN route label for the service 1 are advertised in separate UPDATE messages. ADD-PATH[RFC7911] is used to avoid path hiding. S-RR reflects both SRv6-VPN route and MPLS-VPN route to PE1. Since PE1 only supports MPLS, it may discard the SRv6 Service TLV(s) in the BGP Prefix attribute and treat the SRv6-based route as a MPLS-based route for service 1, then there're two MPLS-based routes for the same service 1 on PE1.¶
Depending on whether the Transposition Scheme is used, the following two scenarios are described separately.¶
Scenario 1, the Transposition Scheme is used, the function and/or argument part of sid-1 is encoded in the MPLS Label field of the NLRI of the SRv6-based service route. Then PE1 may choose the route which is originally the SRv6-based route and use the label field in the NLRI of this route as MPLS VPN label for packet encapsulation.¶
Unless the allocation of SRv6 SIDs and MPLS labels on PE2 is aligned to ensure compatibility, the interpretation of the function and/or argument of the SRv6 SID (sid-1 in the example) will lead to incorrect forwarding of the traffic. In the example above, on PE2 the packets may 1) be sent to the wrong service instance, in case the sid-1 function and/or argument value corresponds to an existing MPLS label, or 2) be dropped, in case the value of sid-1 does not correspond to an allocated MPLS label.¶
Scenario 2, the entire sid-1 is encoded in the SRv6 Services TLV and the MPLS Label field of the corresponding NLRI is set to Implicit NULL. The SRv6 Services TLV in the UPDATE messages is discarded by PE1, and from PE1's aspect, it has received a MPLS service route with an Implicit NULL label.¶
It should be noticed that how to deal with the MPLS-based route with an Implicit NULL label is not standardized, different vendors may have different processing procedures which are unpredictable, e.g, set the route to invalid, send the packet to service 1 without the service route label or something else.¶
On PE3, only SRv6 service SID sid-2 is configured for service 2. If the service routes from PE3 are received by PE1, the problems are similar.¶
[RFC9252] specifies that implementations MUST provide a mechanism to control advertisement of SRv6-based BGP service routes on a per neighbor and per service basis.¶
This can be done by configuration. First the network operator must obtain whether the PEs in the network are capable of SRv6-based services. Then the operator should config on PEs or route reflectors based on each PE's capability, the configuration is per neighbor.¶
The above method may be feasible in small-scale networks, but are not applicable to large-scale networks. The main reasons are:¶
+-----+
+---------------|S-RR1|-----------------+
| +-----+ |
| |
| |
| |
| |
| +----------------+ |
PE1-------| |-------PE2---+
| Backbone | |
PE4-------| |-------PE3-+ |
| +----------------+ | |
| | |
| | |
| | |
| +-----+ | |
+---------------|S-RR2|---------------+-+
+-----+
Some may implement service-RRs separately for MPLS and SRv6 when building the network. As shown in figure 2, S-RR1 is for MPLS service routes only and S-RR2 is for SRv6 service routes only. For MPLS-only PEs like PE1, they would only connect to S-RR1 and the situation is similar for SRv6-only PEs(e.g,PE3 and PE4). In this case, the configuration work is less than the scenario above, but,¶
The basic idea is, if the BGP speaker can obtain the capability for SRv6-based services of its peers, the advertisement of SRv6-based BGP service routes can be automatically controlled.¶
[RFC5492] defines the "Capabilities Optional Parameter". A BGP speaker can include a Capabilities Optional Parameter in a BGP OPEN message. This allows BGP speakers to communicate capabilities. The Capabilities Optional Parameter is a triple that includes a one-octet Capability Code, a one-octet Capability length, and a variable-length Capability Value.¶
This document defines a Capability Code for SRv6-based BGP service capability. If a BGP speaker has not sent the SRv6-based BGP service capability in its BGP OPEN message on a particular BGP session, or if it has not received the SRv6-based BGP service capability in the BGP OPEN message from its peer on that BGP session, that BGP speaker MUST NOT send on that session any UPDATE message that includes the SRv6 service TLVs. Like any other BGP capabilities, if the capability for SRv6-based services is enabled or removed, an established session needs to be reset to resend the OPEN message.¶
In this way, the advertisement of SRv6-based BGP service routes is controlled without per neighbor or per-service configuration, which makes it easier to implement and manage in the network. In the co-existence scenario, the SRv6-based service routes would only be exchange between devices that support it based on this capability. There would be no UPDATE message that includes the SRv6 service TLV received by legacy devices.¶
PEs attached to the network, as BGP speakers, SHOULD indicate their ability to advertise and receive SRv6 based service routes through the SRv6 based BGP service capability. If service route reflectors are used in the network deploying SRv6-based services, they MUST support the SRv6-based BGP service capability if there're PEs in the network supporting this capability.¶
This document defines a new Capability Codes option, named "SRv6 Service Capability" with an assigned value <TBD1> to indicate that a BGP speaker supports SRv6-based services. The length of this capability is 1.¶
This extension to BGP does not change the underlying security issues inherent in [RFC5492] and [RFC9252].¶