Skip to main content

SRv6 Argument Signaling for BGP Services
draft-trr-bess-bgp-srv6-args-02

Document Type Active Internet-Draft (individual)
Authors Ketan Talaulikar , Syed Raza , Jorge Rabadan , Wen Lin
Last updated 2023-09-22
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-trr-bess-bgp-srv6-args-02
BESS Working Group                                         K. Talaulikar
Internet-Draft                                                   K. Raza
Updates: 9252 (if approved)                                Cisco Systems
Intended status: Standards Track                              J. Rabadan
Expires: 25 March 2024                                             Nokia
                                                                  W. Lin
                                                        Juniper Networks
                                                       22 September 2023

                SRv6 Argument Signaling for BGP Services
                    draft-trr-bess-bgp-srv6-args-02

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 25 March 2024.

Copyright Notice

   Copyright (c) 2023 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

Talaulikar, et al.        Expires 25 March 2024                 [Page 1]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

   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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Advertisement of SRv6 SID and Arguments . . . . . . . . . . .   3
   3.  End.DT2M Signaling for EVPN ESI Filtering . . . . . . . . . .   4
     3.1.  Advertisement of Ethernet A-D per ES Route  . . . . . . .   5
     3.2.  Advertisement of Inclusive Multicast Ethernet Tag
           Route . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Processing at Ingress PE  . . . . . . . . . . . . . . . .   7
   4.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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.

Talaulikar, et al.        Expires 25 March 2024                 [Page 2]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

   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

Talaulikar, et al.        Expires 25 March 2024                 [Page 3]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

   node alongwith 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].

Talaulikar, et al.        Expires 25 March 2024                 [Page 4]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

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.
   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 to appropriate values to 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':

Talaulikar, et al.        Expires 25 March 2024                 [Page 5]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

  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 proper LBL, LNL, and FL values be set corresponding to
   the supported 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 appropriate values 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

Talaulikar, et al.        Expires 25 March 2024                 [Page 6]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

             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

Talaulikar, et al.        Expires 25 March 2024                 [Page 7]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

       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.

       a.  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.

       b.  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.

       c.  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

Talaulikar, et al.        Expires 25 March 2024                 [Page 8]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

   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.

Talaulikar, et al.        Expires 25 March 2024                 [Page 9]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

                        +--------------------------------+
                        |                                |
                    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

Talaulikar, et al.        Expires 25 March 2024                [Page 10]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

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 can be preserved by 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, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Talaulikar, et al.        Expires 25 March 2024                [Page 11]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

   [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, February
              2015, <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,
              May 2017, <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,
              January 2018, <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,
              July 2018, <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, March 2020,
              <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, 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>.

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, March 2018,
              <https://www.rfc-editor.org/info/rfc8365>.

Authors' Addresses

Talaulikar, et al.        Expires 25 March 2024                [Page 12]
Internet-Draft  SRv6 Argument Signaling for BGP Services  September 2023

   Ketan Talaulikar
   Cisco Systems
   India
   Email: ketant.ietf@gmail.com

   Kamran Raza
   Cisco Systems
   Canada
   Email: skraza@cisco.com

   Jorge Rabadan
   Nokia
   United States of America
   Email: jorge.rabadan@nokia.com

   Wen Lin
   Juniper Networks
   United States of America
   Email: wlin@juniper.net

Talaulikar, et al.        Expires 25 March 2024                [Page 13]