Internet-Draft SRv6 Argument Signaling for BGP Services March 2024
Talaulikar, et al. Expires 20 September 2024 [Page]
Workgroup:
BESS Working Group
Internet-Draft:
draft-ietf-bess-bgp-srv6-args-01
Updates:
9252 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
K. Talaulikar
Cisco Systems
K. Raza
Cisco Systems
J. Rabadan
Nokia
W. Lin
Juniper Networks

SRv6 Argument Signaling for BGP Services

Abstract

RFC9252 defines procedures and messages for SRv6-based BGP services including L3VPN, EVPN, and Internet services. This document updates RFC9252 and provides more detailed specifications for the signaling and processing of SRv6 SID advertisements for BGP Service routes associated with SRv6 Endpoint Behaviors that support arguments.

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 20 September 2024.

▲

Table of Contents

1. Introduction

SRv6 refers to Segment Routing instantiated on the IPv6 data plane [RFC8402]. SRv6 Service SID refers to an SRv6 SID [RFC8402] associated with one of the service specific SRv6 Endpoint behaviors on the advertising Provider Edge (PE) router for Layer-3 Virtual Private Network (L3VPN), Global Internet Routing, and Ethernet Virtual Private Network (EVPN) services as defined in [RFC8986]. [RFC9252] defines the procedures and messages for the signaling of BGP services including L3VPN, EVPN, and Internet services using SRv6 as data plane.

For some of the EVPN services, [RFC8986] introduced the End.DT2M SRv6 Endpoint Behavior that takes arguments (i.e., Arg.FE2). [RFC9252] specified the encoding and procedures for signaling of the SRv6 SID and its argument via EVPN Route Type 3 and EVPN Route Type 1 respectively. During the implementation and interoperability testing, it was identified that the specifications in [RFC9252] were not detailed adequately.

This document updates [RFC9252] to provide the necessary details and clarifications related to the signaling of SRv6 Service SIDs corresponding to SRv6 Endpoint Behaviors that use arguments. While the document refers more specifically to the signaling of the End.DT2M SRv6 Endpoint Behavior via EVPN Route Types 1 and 3, the procedures can be applied to the signaling of other similar endpoint behaviors with arguments that may be signaled via BGP.

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Advertisement of SRv6 SID and Arguments

As defined in [RFC8986], an SRv6 SID consists of three parts: Locator (LOC), Function (FUNC), and Argument (ARG). SRv6 SIDs corresponding to SRv6 Endpoint Behaviors that do not support argument do not have the ARG part, hence all the bits after FUNC MUST be zero and have zero argument length.

Certain SRv6 Endpoint Behaviors (e.g., End.DT2M), support arguments. As indicated in section 3.2.1 of [RFC9252], the SRv6 SID Structure sub-sub-TLV MUST be signaled along with SRv6 SID corresponding to behaviors that support argument to enable the receiving router to perform consistency checking for the argument and to perform correct encoding of ARG value within the SRv6 SID.

While for some use cases, the SRv6 SID can be signaled as LOC:FUNC:ARG all encoded within the SID, there are use cases where the SRv6 SID (i.e., LOC:FUNC part) is signaled without the ARG via one advertisement and its ARG value is signaled via another advertisement or learnt via some other mechanism. It is the SRv6 Source Node that needs to encode the ARG after the LOC:FUNC part to form the complete SRv6 SID (LOC:FUNC:ARG) that can be used in the data path and encoded in either the packet's IPv6 destination address or as a segment in the Segment Routing Header (SRH) [RFC8754], as required.

Since arguments may be optional, the SRv6 Endpoint Node that owns the SID indicates the SRv6 SID Structure along with the advertisement of the LOC:FUNC part of the SRv6 SID to indicate its support for ARGs for that specific SID. Using a zero Argument Length (AL) indicates that the node does not accept ARG for the given SRv6 SID. Using a non-zero AL indicates the size of the ARG that is supported by the node along with the Locator Block Length (LBL), Locator Node Length (LNL), and Function Length (FL) indicating the offset at which the node expects the ARG value to be encoded.

The advertisement of the ARG value may be done by the same node that owns the SRv6 SID and is doing the advertisement of the LOC:FUNC parts of that SID, or it may be done by some other node/mechanism. The advertisement of the ARG value needs to indicate the size of the ARG along with the value and the associated SRv6 Endpoint Behavior of the SID. There also needs to be some mechanism to associate the advertisement of the ARG with the SID(s) for which that ARG may be used.

3. End.DT2M Signaling for EVPN ESI Filtering

As specified in [RFC9252], the LOC:FUNC part of the SRv6 SID with End.DT2M behavior is signaled via EVPN Route Type 3 (Inclusive Multicast Ethernet Tag Route) while the ESI Filtering ARG (the Arg.FE2 notation introduced in [RFC8986]) part of the SRv6 SID is signaled via EVPN Route Type 1 (Ethernet A-D per ES Route). The subsections below specify the signaling and processing in more detail as compared to [RFC9252].

ESI Filtering is a split-horizon method that is used for Multi-Homing [RFC7432] or E-Tree procedures [RFC8317]. ESI Filtering is not used where there is no E-Tree leaf Broadcast, Unknown Unicast, or Multicast (BUM) traffic, no multi-homing, no split-horizon method used, or where "local-bias" method (refer [RFC8365]) is used. In this document we generically refer to "ESI Filtering" as the procedure carried out by the disposition PE to avoid forwarding BUM traffic to local Ethernet Segments or local leaf attachment circuits, based on the presence of the ESI Filtering ARG.

The description and the examples in this section do not use the Transposition Scheme. Hence, the Transposition Offset (TPOS-O) and Transposition Length (TPOS-L) are both shown to be 0 and the various MPLS label fields into which the FUNC or ARG portions may be transposed into are also not described. The same examples could use the Transposition Scheme. This document does not introduce any change with respect to the use of the Transposition Scheme in the signaling of EVPN Routes and implementations need to follow the procedures and recommendations related to the Transposition Schemed as specified in [RFC9252].

3.1. Advertisement of Ethernet A-D per ES Route

Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1) defined in [RFC7432] are used to achieve split-horizon filtering and fast convergence, in case of multi-homing. A-D per ES routes are also used to enable egress filtering of BUM traffic originated from a Leaf, as specified in [RFC8317].

When ESI Filtering is not in use, there is no ESI Filtering ARG to be conveyed. However, the advertisement of this route SHOULD include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an SRv6 Service SID with the value ::0 is carried in the SRv6 SID Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M. The presence of BGP Prefix-SID Attribute carrying an SRv6 L2 Service TLV indicates support for SRv6 as specified in [RFC9252]. Since the End.DT2M behavior supports the use of ARG, an SRv6 SID Structure sub-sub-TLV MUST be included, and as no ARG value needs to be signaled, the AL MUST be set to 0.

Following is an example representation of the BGP Prefix-SID Attribute encoding in this case:

BGP Prefix SID Attr:
    SRv6 L2 Service TLV:
        SRv6 SID Information sub-TLV:
            SID: ::0
            Behavior: End.DT2M
            SRv6 SID Structure sub-sub-TLV:
                LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0
Figure 1: EVPN Route Type 1 without ARG for ESI Filtering

When ESI Filtering is in use, the advertisement of this route MUST include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying the SRv6 Service SID containing the ESI Filtering ARG value in the SRv6 SID Information sub-TLV (when not using the Transposition Scheme) with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of ARG, an SRv6 SID Structure sub-sub-TLV MUST be included. Also, as there is a non-zero ARG value being signaled, the AL MUST be set to the size of the ARG and the size SHOULD be a multiple of 8. The SRv6 SID Structure sub-sub-TLV has the LBL, LNL, and FL set with values that indicate the offset at which the ARG value is encoded in the 128-bit SID.

Following is an example representation of the BGP Prefix-SID Attribute encoding in this case for a 16-bit argument value 'aaaa':

BGP Prefix SID Attr:
    SRv6 L2 Service TLV:
        SRv6 SID Information sub-TLV:
            SID: 0:0:0:0:aaaa::
            Behavior: End.DT2M
            SRv6 SID Structure sub-sub-TLV:
                LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0
Figure 2: EVPN Route Type 1 with ARG for ESI Filtering

In the above examples, it would have been possible to set the LBL, LNL, and FL values to 0 and to set the SID value as either ::0 or aaaa::. However, such an encoding would not be backwards compatible with [RFC9252] as described further in Section 4 and hence it is REQUIRED that the LBL, LNL, and FL values be set as indicated via the SID Structure for the End.DT2M SRv6 Service SIDs.

3.2. Advertisement of Inclusive Multicast Ethernet Tag Route

Inclusive Multicast Ethernet Tag Route (EVPN Route Type 3) defined in [RFC7432] is used to advertise multicast traffic reachability information through MP-BGP to all other PEs in a given EVPN instance. When using the SRv6 transport, the advertisement of this route MUST include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV to indicate the use of SRv6.

Irrespective of whether ESI Filtering is in use, an SRv6 Service SID with the LOC:FUNC part alone is carried in the SRv6 SID Information sub-TLV (when not using the Transposition Scheme) with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of ARG, an SRv6 SID Structure sub-sub-TLV MUST be included. The LBL, LNL, and FL MUST be set to indicate the structure of the Service SID being signaled.

When ESI Filtering is not in use, no ARG is expected to be received by the router along with the signaled Service SID and hence the AL MUST be set to 0.

Following is an example representation of the BGP Prefix-SID Attribute encoding in this case:

BGP Prefix SID Attr:
    SRv6 L2 Service TLV:
        SRv6 SID Information sub-TLV:
            SID: 2001:db8:1:fbd1::
            Behavior: End.DT2M
            SRv6 SID Structure sub-sub-TLV:
                LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0
Figure 3: EVPN Route Type 3 without ESI Filtering

When ESI Filtering is in use, an ARG is expected to be received by the router along with the signaled Service SID and hence the AL MUST be set to the size of the ARG supported by the advertising router for the specific Service SID. The AL is unique per End.DT2M behavior signaled by the egress PE and, therefore, the egress PE MUST use the same AL for all the local Ethernet Segments with Attachment Circuits in the same Broadcast Domain.

Following is an example representation of the BGP Prefix-SID Attribute encoding in this case for a 16-bit argument:

BGP Prefix SID Attr:
    SRv6 L2 Service TLV:
        SRv6 SID Information sub-TLV:
            SID: 2001:db8:1:fbd1::
            Behavior: End.DT2M
            SRv6 SID Structure sub-sub-TLV:
                LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0
Figure 4: EVPN Route Type 3 with ESI Filtering

When ESI Filtering is in use, the advertising router MUST ensure that the size of argument (i.e., AL) signaled in the Route Type 3 and its corresponding Route Type 1 are equal.

3.3. Processing at Ingress PE

An ingress PE receives the LOC:FUNC parts of the SRv6 Service SID to be used for Broadcast, Unknown Unicast, or Multicast (BUM) traffic along with the EVPN Route Type 3 advertisements.

In the case where ESI Filtering is not used, the SRv6 Service SID to be used is all what is received via the EVPN Route Type 3 (i.e., LOC:FUNC parts alone).

When ESI filtering is used, the ESI Filtering ARG of the SRv6 Service SID is signaled along with EVPN Route Type 1 (Ethernet A-D per ES Route). This ARG along with the LOC:FUNC parts advertised via the EVPN Route Type 3 forms the SRv6 Service SID to be used.

Following are the processing steps to be used at the ingress PE:

  1. When AL=0 is signaled via Route Type 3, then the egress PE does not support or does not require ESI Filtering ARG for the specific SID. The SRv6 Service SID is formed with the LOC:FUNC parts alone and all bits after LBL+LNL+FL MUST be set to zero for encoding on the data path. In this case, the router MUST ignore the SID value and its SID structure advertised in the corresponding Route Type 1.

  2. When a non-zero AL is signaled via Route Type 3, then the matching Route Type 1 for the Ethernet Segment is found and checked for the presence of an SRv6 SID advertisement with the End.DT2M behavior.

    1. If the AL=0 in the Route Type 1, then there is no usable ARG value. In such cases, the SRv6 Service SID to be used is formed as in (1) above.

    2. If the AL values in Route Type 1 and 3 are both non-zero and not equal, then there is no usable ARG value. It also indicates an inconsistency in signaling from the egress PE. To avoid looping, the BUM traffic MUST NOT be forwarded for such routes from the specific Ethernet Segment and implementations SHOULD log an error message.

    3. The ARG value from Route Type 1 is usable only when its AL is equal to the AL of the SID structure advertised via Route Type 3. Once the usable ARG value is obtained, it MUST be encoded within the rest of the SRv6 SID (LOC:FUNC parts) at the offset of the ARG as indicated by the SID structure (i.e., LBL+LNL+FL) in Route Type 3 and the bits after LBL+LNL+FL+AL set to zero.

Since the LOC:FUNC and the ARG portions of the SRv6 Service SID are signaled via different route advertisements, there can be conditions where the ingress PE gets inconsistent ALs from the two route types. If the ingress PE expected ESI filtering to be in use (i.e., when forwarding BUM traffic to other PEs attached to a shared Ethernet Segment) but does not find a usable ARG value during the above processing, it SHOULD log a message to help with troubleshooting.

Based on the above procedures, the SRv6 Service SID encoding for the data plane without an ESI Filtering ARG, based on the examples in Figure 1 and Figure 3, is as follows:

Route Type 3:
 SID: 2001:db8:1:fbd1::
 Structure: LBL: 32, LNL: 16, FL: 16, AL: 0

SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1::
Figure 5: SRv6 Service SID Encoding for Data Plane without ARG

Based on the above procedures, the SRv6 Service SID encoding for the data plane along with an ESI Filtering ARG, based on the examples in Figure 2 and Figure 4, is as follows:

Route Type 1:
 SID: 0:0:0:0:aaaa::
 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16

Route Type 3:
 SID: 2001:db8:1:fbd1::
 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16

SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1:aaaa::
Figure 6: SRv6 Service SID Encoding for Data Plane with ARG

Figure 7 below provides another example that illustrates the signaling and processing of multiple bridge domains in a deployment design.

                     +--------------------------------+
                     |                                |
                 PE1 |                                |
                 +---------+                          |
  BUM on BD1     | +-----+ |                          |
+----------------> | BD1 |-------------+              |
|                | +-----+ |           |              |
|  BUM on BD2    | +-----+ |           v          PE3 |
| +--------------> | BD2 |-------+             +---------+
| |        +-----| +-----+ |     |             | +-----+ |
+----+     |     +---------+     v     ^       | | BD1 |-----CE31
|    |     |         |                 |       | +-----+ |
|CE12|-----+ ESI-1   |           ^     |       | +-----+ |
|    |-----+         |           |     |       | | BD2 |-----CE32
+----+     |     +---------+ ^   RT3   RT3     | +-----+ |
           +-----| +-----+ | |   dt2m  dt2m    +---------+
                 | | BD1 | | |   BD2   BD1            |
                 | +-----+ | |   FL:16 FL:32          |
                 | +-----+ | RT1                      |
                 | | BD2 | | ESI-1                    |
                 | +-----+ | AL:16                    |
                 +---------+                          |
                  PE2 |                               |
                      |                               |
                      |                               |
                      +-------------------------------+

 Route Type 1 ESI-1:
  SID: 0:0:0:0:aaaa::
  Structure: LBL: 32, LNL: 16, FL: 16, AL: 16

 Route Type 3 from BD1:
  SID: 2001:db8:1:fbd1:fbd1:
  Structure: LBL: 32, LNL: 16, FL: 32, AL: 16

 Route Type 3 from BD2:
  SID: 2001:db8:1:fbd1::
  Structure: LBL: 32, LNL: 16, FL: 16, AL: 16

 SRv6 Service SID for datapath from ingress PE1 to egress PE on BD1:
  2001:db8:1:fbd1:fbd1:aaaa::
 SRv6 Service SID for datapath from ingress PE1 to egress PE on BD2:
  2001:db8:1:fbd1:aaaa::
Figure 7: Example with Multiple Bridge Domains

4. Backward Compatibility

[RFC9252] section 6.3 specifies the use of a bitwise logical-OR operation between the SID with ARG signaled via Route Type 1 and the SID with LOC:FUNC parts signaled via Route Type 3 to form the SRv6 Service SID to be used in the data path. However, this assumes that the same uniform SID structure is used and signaled for all SIDs advertised via Route Type 3 and the Route Type 1. Such an assumption may not always be correct and the procedures in this document remove this restriction.

Backward compatibility with implementations doing the bitwise logical-OR operation is preserved thanks to the advertisement of SIDs in Route Type 3 and its corresponding Route Type 1 with the same SID structure as described in Section 3.1 and Section 3.2. As an extension, the bitwise logical-OR operation specified in [RFC9252] cannot be used when the SID structures of the two route types are not identical.

5. IANA Considerations

This document does not require any action from IANA.

6. Security Considerations

This document only provides a more detailed specification related to the signaling and processing of SRv6 SID advertisements for SRv6 Endpoint Behaviors with arguments. As such, it does not introduce any new security considerations over and above what is already covered by [RFC9252].

7. Acknowledgments

The authors would like to acknowledge Jayshree Subramanian, Sonal Agarwal, Swadesh Agrawal, Dongling Duan, Luc Andre Burdet, Patrice Brissette, Senthil Sathappan, Erel Ortacdag, Neil Hart, Will Lockhart, and Vinod Prabhu for their inputs on aspects related to the signaling of the End.DT2M SRv6 Endpoint behavior that required clarification as also for their review of this document.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7432]
Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, , <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8317]
Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, , <https://www.rfc-editor.org/info/rfc8317>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754]
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <https://www.rfc-editor.org/info/rfc8754>.
[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, , <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, , <https://www.rfc-editor.org/info/rfc9252>.

8.2. Informative References

[RFC8365]
Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, , <https://www.rfc-editor.org/info/rfc8365>.

Authors' Addresses

Ketan Talaulikar
Cisco Systems
India
Kamran Raza
Cisco Systems
Canada
Jorge Rabadan
Nokia
United States of America
Wen Lin
Juniper Networks
United States of America