BESS Working Group                                         G. Dawra, Ed.
Internet-Draft                                                  LinkedIn
Intended status: Standards Track                           G. Dawra, Ed.
Expires: May 6, 2020                                            LinkedIn                             C. Filsfils
Expires: August 30, 2020                                   Cisco Systems
                                                               R. Raszuk
                                                            Bloomberg LP
                                                             B. Decraene
                                                                  Orange
                                                               S. Zhuang
                                                     Huawei Technologies
                                                              J. Rabadan
                                                                   Nokia
                                                        November 3, 2019
                                                       February 27, 2020

                    SRv6 BGP based Overlay services
                    draft-ietf-bess-srv6-services-01
                    draft-ietf-bess-srv6-services-02

Abstract

   This draft defines procedures and messages for SRv6-based BGP
   services including L3VPN, EVPN and Internet services.  It builds on
   RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432
   "BGP MPLS-Based Ethernet VPN".

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.

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 May 6, August 30, 2020.

Copyright Notice

   Copyright (c) 2019 2020 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  SRv6 Services TLVs  . . . . . . . . . . . . . . . . . . . . .   4
     2.1.
   3.  SRv6 Service Sub-TLVs . . . . . . . . . . . . . . . . . . . .   5
       2.1.1.
     3.1.  SRv6 SID Information Sub-TLV  . . . . . . . . . . . .   5
       2.1.2. . .   6
     3.2.  SRv6 Service Data Sub-Sub-TLVs  . . . . . . . . . . .   6
   3. . .   7
       3.2.1.  SRv6 SID Structure Sub-Sub-TLV  . . . . . . . . . . .   7
   4.  Encoding SRv6 SID information . . . . . . . . . . . . . . . .   9
   5.  BGP based L3 service over SRv6  . . . . . . . . . . . . . . .   9
     3.1.  10
     5.1.  IPv4 VPN Over SRv6 Core . . . . . . . . . . . . . . . . .   9
     3.2.  11
     5.2.  IPv6 VPN Over SRv6 Core . . . . . . . . . . . . . . . . .  10
     3.3.  11
     5.3.  Global IPv4 over SRv6 Core  . . . . . . . . . . . . . . .  10
     3.4.  12
     5.4.  Global IPv6 over SRv6 Core  . . . . . . . . . . . . . . .  10
   4.  12
   6.  BGP based Ethernet VPN (EVPN) over SRv6 . . . . . . . . . . .  11
     4.1.  12
     6.1.  Ethernet Auto-discovery route over SRv6 Core  . . . . . .  11
       4.1.1.  13
       6.1.1.  Per-ES A-D route  . . . . . . . . . . . . . . . . . .  12
       4.1.2.  13
       6.1.2.  Per-EVI A-D route . . . . . . . . . . . . . . . . . .  12
     4.2.  14
     6.2.  MAC/IP Advertisement route over SRv6 Core . . . . . . . .  13
     4.3.  14
       6.2.1.  MAC/IP Advertisement route with MAC Only  . . . . . .  15
       6.2.2.  MAC/IP Advertisement route with MAC+IP  . . . . . . .  16
     6.3.  Inclusive Multicast Ethernet Tag Route over SRv6 Core . .  15
     4.4.  16
     6.4.  Ethernet Segment route over SRv6 Core . . . . . . . . . .  16
     4.5.  18
     6.5.  IP prefix route over SRv6 Core  . . . . . . . . . . . . .  17
     4.6.  18
     6.6.  EVPN multicast routes (Route Types 6, 7, 8) over SRv6
           core  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   5.  Encoding SRv6 SID information . . . . . . . . . . . . . . . .  18
   6.  19
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .  19
   7.
   8.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  19
   8.
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     8.1.
     9.1.  BGP Prefix-SID TLV Types registry . . . . . . . . . . . .  21
     8.2.  20
     9.2.  SRv6 Service Sub-TLV Types registry . . . . . . . . . . .  21
     8.3.
     9.3.  SRv6 Service Data Sub-Sub-TLV Types registry  . . . . . .  21
   9.
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  22
   10. Conclusions . . .  21
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  22
   11. References .  21
   12. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  22
     11.1.  Normative
   13. References  . . . . . . . . . . . . . . . . . .  22
     11.2.  Informative References . . . . . . .  23
     13.1.  Normative References . . . . . . . . . .  23
   Appendix A.  Contributors . . . . . . . .  23
     13.2.  Informative References . . . . . . . . . . . .  25 . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

   SRv6 refers to Segment Routing [RFC8402] instantiated on the IPv6
   dataplane [I-
   D.ietf-spring-srv6-network-programming][I-D.ietf-6man-segment-routing
   -header]. [I-D.ietf-6man-segment-routing-header].

   SRv6 based BGP services refers to the L3 and L2 overlay services with
   BGP as control plane and SRv6 as dataplane.

   SRv6 SID refers to a SRv6 Segment Identifier as defined in
   [I-D.ietf-spring-srv6-network-programming]. [RFC8402].

   SRv6 Service SID refers to an SRv6 SID associated with one of the
   service specific behavior on the advertising Provider Edge(PE) Edge (PE)
   router, such as (but not limited to), END.DT (Table lookup in a VRF)
   or END.DX (cross-connect to a nexthop) behaviors in the case of L3VPN
   service as defined in [I-D.ietf-spring-srv6-network-programming].

   To provide SRv6 service with best-effort connectivity, the egress PE
   signals an SRv6 Service SID with the BGP overlay service route.  The
   ingress PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID provided by the egress
   PE.  The underlay between the PEs only need to support plain IPv6
   forwarding [RFC8200].

   To provide SRv6 service in conjunction with an underlay SLA from the
   ingress PE to the egress PE, the egress PE colors the overlay service
   route with a Color extended community
   [I-D.ietf-idr-segment-routing-te-policy].  The ingress PE
   encapsulates the payload packet in an outer IPv6 header with an SRH
   that contains the
   segment list of SR policy associated with the related SLA followed by
   the SRv6 Service SID associated with the route.  The underlay nodes
   whose SRv6 SID's are part of the SRH segment list MUST support SRv6 data
   plane.

   BGP is used to advertise the reachability of prefixes of a particular
   service from an egress PE to ingress PE nodes.

   This document describes how existing BGP messages between PEs may
   carry SRv6 Service SIDs as a means to interconnect PEs and form VPNs.

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.  SRv6 Services TLVs

   This document extends the BGP Prefix-SID attribute
   [I-D.ietf-idr-bgp-prefix-sid] [RFC8669] to carry
   SRv6 SIDs and associated information.

   The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-
   SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2
   services.

   o  SRv6 L3 Service TLV: This TLV encodes Service SID information for
      SRv6 based L3 services.  It corresponds to the equivalent
      functionality provided by an MPLS Label when received with a Layer
      3 service route.  Some behaviors which MAY be encoded, but not
      limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc.

   o  SRv6 L2 Service TLV: This TLV encodes Service SID information for
      SRv6 based L2 services.  It corresponds to the equivalent
      functionality provided by an MPLS Label1 for EVPN Route-Types as
      defined in[RFC7432].  Some behaviors which MAY be encoded, but not
      limited to, are End.DX2, End.DX2V, End.DT2U, End.DT2M etc.

   When an egress PE is enabled for BGP Services over SRv6 data-plane,
   it MUST signal one or more SRv6 Service SIDs enclosed in SRv6 Service
   TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs
   defined in [RFC4760][RFC4659][RFC5549][RFC7432][RFC4364] [RFC4760] [RFC4659] [I-D.ietf-bess-rfc5549revision]
   [RFC7432] [RFC4364] where applicable as described in section 3 Section 5 and 4.
   Section 6.

   The following depicts the SRv6 Service TLVs encoded in the BGP
   Prefix-SID Attribute:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   TLV Type    |         TLV Length            |   RESERVED    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //  SRv6 Service Sub-TLVs                                      //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  TLV Type (1 octet): This field is assigned values from the IANA
      registry "BGP Prefix-SID TLV Types".  It is set to [TBD1] TBD1 (to be
      assigned by IANA) for SRv6 L3 Service TLV.  It is set to [TBD2] TBD2 (to
      be assigned by IANA) for SRv6 L2 Service TLV.

   o  TLV Length (2 octets): Specifies the total length of the TLV
      Value.

   o  RESERVED (1 octet): This field is reserved; it SHOULD be set to 0
      by the sender and MUST be ignored by the receiver.

   o  SRv6 Service Sub-TLVs (variable): This field contains SRv6 Service
      related information and is encoded as an unordered list of Sub-
      TLVs whose format is described below.

2.1.

   A BGP speaker receiving a route containing BGP Prefix-SID Attribute
   with one or more SRv6 Service TLVs observes the following rules when
   advertising the received route to other peers:

   o  if the nexthop is unchanged during advertisement, the SRv6 Service
      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.

   o  if the nexthop is changed, the TLVs, Sub-TLVs and Sub-Sub-TLVs
      SHOULD be updated as appropriate.  Any unrecognized received sub-
      TLVs and Sub-Sub-TLVs MUST be removed.

3.  SRv6 Service Sub-TLVs

   The format of a single SRv6 Service Sub-TLV is depicted below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | SRv6 Service  |    SRv6 Service               | SRv6 Service //
    | Sub-TLV       |    Sub-TLV                    | Sub-TL Sub-TLV      //
    | Type          |    Length                     | value        //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  SRv6 Service Sub-TLV Type (1 octet): Identifies the type of SRv6
      service information.  It is assigned values from the IANA Registry
      "SRv6 Service Sub-TLV Types".

   o  SRv6 Service Sub-TLV Length (2 octets): Specifies the total length
      of the Sub-TLV Value field.

   o  SRv6 Service Sub-TLV Value (variable): Contains data specific to
      the Sub-TLV Type.  In addition to fixed length data, this may also
      optionally contain it contains
      other properties of the SRv6 Service encoded as a set of SRv6
      Service Data Sub-Sub-TLVs whose format is described in another sub-section Section 3.2
      below.

2.1.1.

3.1.  SRv6 SID Information Sub-TLV

   SRv6 Service Sub-TLV Type 1 is assigned for SRv6 SID Information Sub-
   TLV.  This Sub-TLV contains a single SRv6 SID along with its
   properties.  Its encoding is depicted below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | SRv6 Service  |    SRv6 Service               |               |
       | Sub-TLV       |    Sub-TLV                    |               |
       | Type=1        |    Length                     |  RESERVED2  RESERVED1    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //  SRv6 SID Value (16 bytes)                                  //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | SRv6 SID Flags|  SRv6 Endpoint Behavior        |  RESERVED3  RESERVED2   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //  SRv6 Service Data Sub-Sub-TLVs                             //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to
      represent SRv6 SID Information Sub-TLV.

   o  SRv6 Service Sub-TLV Length (2 octets): This field contains the
      total length of the Value field of the Sub-TLV.

   o  RESERVED2  RESERVED1 (1 octet): SHOULD be set to 0 by the sender and MUST be
      ignored by the receiver.

   o  SRv6 SID Value (16 octets): Encodes an SRv6 SID as defined in
      [I-D.ietf-spring-srv6-network-programming]

   o  SRv6 SID Flags (1 octet): Encodes SRv6 SID Flags - none are
      currently defined.

   o  SRv6 Endpoint Behavior (2 octets): Encodes SRv6 Endpoint behavior
      defined in [I-D.ietf-spring-srv6-network-programming].  This field
      SHOULD be set to the
      codepoint value 0xFFFF indicating opaque behavior
      unless the router wants to signal from the actual behavior. IANA registry defined in section 9.2 of
      [I-D.ietf-spring-srv6-network-programming] that is associated with
      SRv6 SID.

   o  RESERVED3  RESERVED2 (1 octet): SHOULD be set to 0 by the sender and MUST be
      ignored by the receiver.

   o  SRv6 Service Data Sub-Sub-TLV Value (variable): This field
      contains optional Used to advertise
      properties of the SRv6 SID.  It is encoded as a set of SRv6
      Service Data Sub-Sub-TLVs.

2.1.2.

   When multiple SRv6 SID Information Sub-TLVs are present, the ingress
   PE SHOULD use the SRv6 SID from the first instance of the Sub-TLV.
   An implementation MAY provide a local policy to override this
   selection.

3.2.  SRv6 Service Data Sub-Sub-TLVs

   The format of the SRv6 Service Data Sub-Sub-TLV is depicted below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Service Data |  Sub-sub-TLV  Sub-Sub-TLV Length               |Sub-sub               |Sub-Sub TLV //
      | Sub-Sub-TLV  |                                   |  Value     //
      | Type         |                                   |            //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  SRv6 Service Data Sub-Sub-TLV Type (1 octet): Identifies the type
      of Sub-Sub-TLV.  It is assigned values from the IANA Registry
      "SRv6 Service Data Sub-Sub-TLVs".

   o  SRv6 Service Data Sub-Sub-TLV Length (2 octets): Specifies the
      total length of the Sub-Sub-TLV Value field.

   o  SRv6 Service Data Sub-Sub-TLV Value (variable): Contains data
      specific to the Sub-Sub-TLV Type.

2.1.2.1.

3.2.1.  SRv6 SID Structure Sub-Sub-TLV

   SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for SRv6 SID
   structure Sub-Sub-TLV.  SRv6 SID Structure Sub-Sub-TLV is used to
   advertise the lengths of each individual parts of the SRv6 SID as
   defined in [I-D.ietf-spring-srv6-network-programming].  It is carried
   as Sub-Sub-TLV in SRv6 SID Information Sub-TLV

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | SRv6 Service  |    SRv6 Service               | Locator Block |
       | Data Sub-Sub  |    Data Sub-Sub-TLV           | Length        |
       | -TLV Type=1   |    Length=6                   |               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Locator Node  | Function      | Argument      | Transposition |
       | Length        | Length        | Length        | Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Transposition |
       | Offset        |
       +-+-+-+-+-+-+-+-+

   o  SRv6 Service Data Sub-Sub-TLV Type (1 octet): This field is set to
      1 to represent SRv6 SID Structure Sub-Sub-TLV.

   o  SRv6 Service Data Sub-Sub-TLV Length (2 octets): This field
      contains the total length of 6 bytes.

   o  Locator Block Length(1 Length (1 octet): Contains length of SRv6 SID
      locator Block in bits.

   o  Locator Node Length(1 Length (1 octet): Contains length of SRv6 SID locator
      Node in bits.

   o  Function Length(1 Length (1 octet): Contains length of SRv6 SID Function in
      bits.

   o  Arguments Length(1 octet): Contains  Argument Length (1 octet): Contains length of SRv6 SID arguments argument in
      bits.

   o  Transposition Length(1 Length (1 octet): Size in bits for the part of SID
      that has been transposed (or shifted) into a label field

   o  Transposition Offset(1 Offset (1 octet): The offset position in bits for
      the part of SID that has been transposed (or shifted) into a label
      field.

   Section 5 4 describes mechanisms for signaling of the SRv6 Service SID
   by transposing a variable part of the SRv6 SID value (function and/or
   the argument parts) and carrying them in existing label fields to
   achieve more efficient packing of those service prefix NLRIs in BGP
   update messages.  The SRv6 SID Structure Sub-Sub-TLV MUST be included
   with the contains
   appropriate length fields when the SRv6 Service SID is signaled in
   split parts to enable the receiver to put together the SID
   accurately.

   Transposition Offset indicates the bit position and Transposition
   Length indicates the number of bits that are being taken out of the
   SRv6 SID value and put into high order bits of label field.  The bits
   that have been shifted out MUST be set to 0 in the SID value.

   Transposition Offset MUST be byte aligned.

   Transposition Length of 0 indicates nothing is transposed and that
   the entire SRv6 SID value is encoded in the SID Information sub-TLV.
   In this case, the Transposition Offset MUST be set to 0.

   Since size of label field is 24 bits, only that many bits can be
   transposed from the SRv6 SID value into it.

   The

   As an example, when the entire function part of size 16 of an SRv6
   SID Structure Sub-Sub-TLV is optional transposed and MAY the sum of the locator block and locator node
   parts is 64, then the transposition offset would be included
   when set to 64 and the
   transposition length is set to 16.

   BGP speakers that do not support this specification may misinterpret,
   on reception of an SRv6-based BGP service route update, the function
   and/or argument parts of the entire SRv6 Service SID value is encoded in the SID
   Information Sub-TLV. label field(s) as
   MPLS label values for MPLS-based services.  Implementations
   supporting this specification SHOULD provide a mechanism to control
   advertisement of SRv6-based BGP service routes on a per neighbor and
   per service basis.

   Arguments MAY be generally applicable for SIDs of only specific
   behaviors (e.g.  End.DT2M) and therefore the argument length MUST be
   set to 0 for SIDs where the argument is not applicable.

3.  BGP based L3 service over

4.  Encoding SRv6

   BGP egress nodes (egress PEs) advertise a set of reachable prefixes.
   Standard BGP update propagation schemes[RFC4271], which may make use
   of route reflectors [RFC4456], are used to propagate these prefixes.
   BGP ingress nodes (ingress PEs) receive these advertisements and may
   add the prefix to the RIB in an appropriate VRF.

   Egress PEs which supports SID information

   The SRv6 based L3 services advertises overlay
   service prefixes along with Service SID(s) for a BGP Service SID enclosed Prefix are carried in a the
   SRv6 L3
   Service TLV within Services TLVs of the BGP Prefix-SID Attribute.  This TLV serves two
   purposes - first, it indicates that the egress PE

   For certain types of BGP Services like L3VPN where a per-VRF SID
   allocation is reachable via an
   SRv6 underlay and used (i.e.  End.DT4 or End.DT6 behaviors), the BGP ingress PE receiving this route MUST choose
   to perform IPv6 encapsulation and optionally insert an SRH when
   required; second ,it indicates same SID
   is shared across multiple NLRIs thus providing efficient packing.
   However, for certain other types of BGP Services like EVPN VPWS where
   a per-PW SID allocation is required (i.e.  End.DX2 behavior), each
   NLRI would have its own unique SID there by resulting in inefficient
   packing.

   To achieve efficient packing, this document allows the value encoding of
   the SRv6 Service SID to be
   used either as a whole in the encapsulation.

   The Service SID thus signaled SRv6 Services TLVs or
   the encoding of only has local significance at the
   egress PE, where it may be allocated or configured on a per-CE or
   per-VRF basis.  In practice, common part of the SID may encode a cross-connect to a
   specific Address Family table (END.DT) or next-hop/interface (END.DX)
   as defined in [I-D.ietf-spring-srv6-network-programming].

   The SRv6 Service SID SHOULD be routable within (e.g.  Locator)
   in the AS of SRv6 Services TLVs and encoding the egress
   PE variable (e.g.  Function
   and serves Argument parts) in the dual purpose existing label fields specific to that
   service encoding.  This later form of providing reachability between
   ingress PE and egress PE while also encoding is referred to as the endpoint behavior.

   At an ingress PE, BGP installs the received prefix in the correct RIB
   table, recursing via an SR Policy leveraging
   Transposition Scheme where the received SRv6
   Service SID.

   Assuming best-effort connectivity to SID Structure Sub-Sub-TLV
   describes the egress PE, sizes of the SR policy has
   a path with a SID list made up parts of a single SID - the SRv6 Service SID
   received and to also indicate
   offset of variable part along with its length in SRv6 SID value.  The
   use of the related BGP route update.

   However, when the received route Transposition Scheme is colored with an extended color
   community 'C' and Next-Hop 'N', RECOMMENDED for the specific
   service encodings that allow it as described further in Section 5 and
   Section 6.

   As an example, for the ingress PE has a valid SRv6
   Policy (C, N) associated with SID list <S1,S2, S3> [I-D.filsfils-
   spring-segment-routing-policy], then EVPN VPWS service prefix described further in
   Section 6.1.2, the effective SR Policy is <S1,
   S2, S3-Service-SID>.

   Multiple VPN routes MAY resolve recursively via function part of the same SR Policy.

3.1.  IPv4 VPN Over SRv6 Core

   The MP_REACH_NLRI for SRv6 core SID is encoded according to IPv4 VPN Over
   IPv6 Core defined in [RFC5549]. the
   MPLS Label field of IPv4-VPN NLRI is set to Implicit NULL when the SID
   Structure Sub-Sub-TLV is not present or when it is present NLRI and
   indicates that the Function is encoded in the SID value (refer
   Section 5 for details).  Otherwise it in the SRv6 Services
   TLV carries only the Function locator part of
   SRv6 SID when indicated as such by with the SRv6 SID Structure Sub-Sub-TLV. Sub-
   Sub-TLV.  The SRv6 Service SID is encoded as part of Structure sub-sub-TLV defines the SRv6 L3 Service TLV.  The
   behavior lengths of
   locator block, locator node and function parts (arguments are not
   applicable for the SRv6 SID is entirely up to End.DX2 behavior).  Transposition Offset indicates
   the originator bit position and Transposition Length indicates the number of
   bits that are being taken out of the
   advertisement. SID and put into label field.

   In practice, yet another example, for the behavior SHOULD EVPN Per-ES A-D route described
   further in Section 6.1.1, only the argument of the SID needs to be End.DX4 or
   End.DT4.

3.2.  IPv6 VPN Over
   signaled.  This argument part of the SRv6 Core

   The MP_REACH_NLRI for SRv6 core is encoded according to IPv6 VPN over
   IPv6 Core is defined SID MAY be transposed in [RFC4659].
   the ESI Label field set to Implicit NULL when of the SID Structure Sub-Sub-TLV
   is not present or when it is present ESI Label Extended Community and indicates that the Function
   is encoded in the SID
   value (refer Section 5 for details).  Otherwise
   it carries in the Function part of SRv6 SID when indicated as such by Services TLV is set to 0 with the SRv6 SID
   Structure Sub-Sub-TLV.

   SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.  The
   behavior of the SRv6 SID is entirely up to Structure sub-sub-TLV defines
   the originator lengths of the
   advertisement.  In practice, the behavior SHOULD be End.DX6 or
   End.DT6.

3.3.  Global IPv4 over SRv6 Core locator block, locator node, function and argument
   parts.  The MP_REACH_NLRI for SRv6 core is encoded according offset and length of argument part SID value moved to IPv4 over
   IPv6 Core
   label field is defined set in [RFC5549].

   SRv6 Service SID is encoded as part transposition offset and length of the SRv6 L3 Service SID
   structure TLV.  The
   behavior of the SRv6 SID receiving router is entirely up then able to put together the originator of the
   advertisement.  In practice, the behavior SHOULD be End.DX4 or
   End.DT4.

3.4.  Global IPv6 over SRv6 Core

   The MP_REACH_NLRI for SRv6 core is encoded according to [RFC2545]
   entire SRv6 Service SID is encoded as part of (e.g.  for the SRv6 L3 Service TLV.  The
   behavior of End.DT2M behavior) placing the SRv6 SID is entirely up to
   label value received in the originator ESI Label field of the
   advertisement.  In practice, Per-ES A-D route
   into the behavior SHOULD be End.DX6 or
   End.DT6.

   Also, by utilizing correct transposition offset and length in the SRv6 L3 Service TLV to encode SID with
   the Global SID, End.DT2M behavior received for a BGP free core is possible by encapsulating all BGP traffic from
   edge to edge over SRv6 dataplane.

4. EVPN Route Type 3 value.

5.  BGP based Ethernet VPN (EVPN) L3 service over SRv6

   Ethernet VPN(EVPN), as defined in [RFC7432] provides an extendable
   method

   BGP egress nodes (egress PEs) advertise a set of building an EVPN overlay.  It primarily focuses on MPLS
   based EVPNs but calls out reachable prefixes.
   Standard BGP update propagation schemes[RFC4271], which may make use
   of route reflectors [RFC4456], are used to propagate these prefixes.
   BGP ingress nodes (ingress PEs) receive these advertisements and may
   add the extensibility prefix to IP based EVPN
   overlays.  [RFC7432] defines 4 Route Types the RIB in an appropriate VRF.

   Egress PEs which carry supports SRv6 based L3 services advertises overlay
   service prefixes along with a Service SID enclosed in a SRv6 L3
   Service TLV within the BGP Prefix-SID Attribute.  This TLV serves two
   purposes - first, it indicates that the egress PE supports SRv6
   overlay and
   MPLS Label fields; the Label fields have specific use for MPLS
   encapsulation of EVPN traffic.  Route Type 5 carrying MPLS label
   information (and thus BGP ingress PE receiving this route MUST choose to
   perform IPv6 encapsulation information) for EVPN is defined
   in [I-D.ietf-bess-evpn-prefix-advertisement].  Route Types 6, 7 and 8
   are defined optionally insert an SRH when
   required; second ,it indicates the value of the Service SID to be
   used in [I-D.ietf-bess-evpn-igmp-mld-proxy].

   o  Ethernet Auto-discovery Route (Route Type 1)

   o  MAC/IP Advertisement Route (Route Type 2)

   o  Inclusive Multicast Ethernet Tag Route (Route Type 3)

   o  Ethernet Segment route (Route Type 4)

   o  IP prefix route (Route Type 5)

   o  Selective Multicast Ethernet Tag route (Route Type 6)

   o  IGMP join sync the encapsulation.

   The Service SID thus signaled only has local significance at the
   egress PE, where it may be allocated or configured on a per-CE or
   per-VRF basis.  In practice, the SID may encode a cross-connect to a
   specific Address Family table (END.DT) or next-hop/interface (END.DX)
   as defined in [I-D.ietf-spring-srv6-network-programming].

   The SRv6 Service SID SHOULD be routable within the AS of the egress
   PE and serves the dual purpose of providing reachability between
   ingress PE and egress PE while also encoding the endpoint behavior.

   When the egress PE sets the next-hop to a value that is not covered
   by the SRv6 Locator from which the SRv6 Service SID is allocated,
   then the ingress PE SHOULD perform reachability check for the SRv6
   Service SID in addition to the BGP next-hop reachability procedures.

   At an ingress PE, BGP installs the received prefix in the correct RIB
   table, recursing via an SR Policy leveraging the received SRv6
   Service SID.

   Assuming best-effort connectivity to the egress PE, the ingress PE
   encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route (Route Type 7)

   o  IGMP leave sync update.

   However, when the received route (Route Type 8)

   To support is colored with an extended color
   community 'C' and Next-Hop 'N', and the ingress PE has a valid SRv6 based EVPN overlays, one
   Policy (C, N) associated with SID list <S1,S2, S3>
   [I-D.ietf-spring-segment-routing-policy], then the effective SR
   Policy is <S1, S2, S3-Service-SID>.

   Multiple VPN routes MAY resolve recursively via the same SR Policy.

5.1.  IPv4 VPN Over SRv6 Core

   The MP_REACH_NLRI for SRv6 core is encoded according to IPv4 VPN Over
   IPv6 Core defined in [I-D.ietf-bess-rfc5549revision].

   Label field of IPv4-VPN NLRI carries the Function part of the SRv6
   SID when the Transposition Scheme of encoding (Section 4) is used and
   otherwise set to Implicit NULL.

   SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.  The
   behavior of the SRv6 SID is entirely up to the originator of the
   advertisement.  In practice, the behavior is End.DX4 or End.DT4.

5.2.  IPv6 VPN Over SRv6 Core

   The MP_REACH_NLRI for SRv6 core is encoded according to IPv6 VPN over
   IPv6 Core is defined in [RFC4659].

   Label field of the IPv6-VPN NLRI carries the Function part of the
   SRv6 SID when the Transposition Scheme of encoding (Section 4) is
   used and otherwise set to Implicit NULL.

   SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.  The
   behavior of the SRv6 SID is entirely up to the originator of the
   advertisement.  In practice, the behavior is End.DX6 or End.DT6.

5.3.  Global IPv4 over SRv6 Core

   The MP_REACH_NLRI for SRv6 core is encoded according to IPv4 over
   IPv6 Core is defined in [I-D.ietf-bess-rfc5549revision].

   SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.  The
   behavior of the SRv6 SID is entirely up to the originator of the
   advertisement.  In practice, the behavior is End.DX4 or more End.DT4.

5.4.  Global IPv6 over SRv6 Service SIDs
   are advertised with Route Type 1,2,3 and 5. Core

   The MP_REACH_NLRI for SRv6 Service SID(s)
   per Route Type are advertised in core is encoded according to [RFC2545]

   SRv6 L3/L2 Service TLVs within the
   BGP Prefix-SID Attribute.  Signaling SID is encoded as part of the SRv6 L3 Service SID(s) serves
   two purposes - first, it indicates that TLV.  The
   behavior of the BGP egress device is
   reachable via an SRv6 underlay and the BGP ingress device receiving
   this route MUST choose SID is entirely up to perform IPv6 encapsulation and optionally
   insert an SRH when required; second, it indicates the value originator of the
   Service SID(s) to be used in
   advertisement.  In practice, the encapsulation.

4.1. behavior is End.DX6 or End.DT6.

6.  BGP based Ethernet Auto-discovery route VPN (EVPN) over SRv6 Core

   [RFC7432] provides an extendable method of building an Ethernet Auto-Discovery (A-D) routes are Route Type 1 defined in
   [RFC7432]and may be used to achieve split horizon filtering, fast
   convergence VPN
   (EVPN) overlay.  It primarily focuses on MPLS based EVPNs and aliasing.
   [RFC8365] extends to IP based EVPN overlays.  [RFC7432] defines Route Type 1 is also used in EVPN-
   VPWS as well as in EVPN flexible cross-connect; mainly used to
   advertise point-to-point services ID.

   Multi-homed PEs MAY advertise an Ethernet Auto-Discovery route per
   Ethernet segment along with the ESI
   Types 1, 2 and 3 which carry prefixes and MPLS Label extended community defined
   in [RFC7432].  PEs may identify other PEs connected to the same
   Ethernet segment after fields; the
   Label fields have specific use for MPLS encapsulation of EVPN
   traffic.  Route Type 5 carrying MPLS label information (and thus
   encapsulation information) for EVPN is defined in
   [I-D.ietf-bess-evpn-prefix-advertisement].  Route Type 4 ES route exchange.  All
   the multi-homed Types 6,7 and remote PEs that 8 are part of same EVI may import
   the Auto-Discovery route.

   EVPN
   defined in [I-D.ietf-bess-evpn-igmp-mld-proxy].

   o  Ethernet Auto-discovery Route (Route Type 1 is encoded as follows for SRv6 Core:

                   +---------------------------------------+
                   |  RD (8 octets)                        |
                   +---------------------------------------+
                   |Ethernet Segment Identifier (10 octets)|
                   +---------------------------------------+
                   | 1)

   o  MAC/IP Advertisement Route (Route Type 2)

   o  Inclusive Multicast Ethernet Tag ID (4 octets)           |
                   +---------------------------------------+
                   |  MPLS label (3 octets)                |
                   +---------------------------------------+

4.1.1.  Per-ES A-D Route (Route Type 3)

   o  Ethernet Segment route (Route Type 4)

   o  BGP next-hop: IPv6 address of an egress PE  IP prefix route (Route Type 5)

   o  Selective Multicast Ethernet Tag ID: set to MAX-ET per [RFC7432] section 8.2.1 route (Route Type 6)

   o  MPLS Label: always set to zero per [RFC7432] section 8.2.1  IGMP join sync route (Route Type 7)

   o  ESI label extended community ESI label field: It is set to
      Implicit NULL when the SID Structure Sub-Sub-TLV is not present  IGMP leave sync route (Route Type 8)

   To support SRv6 based EVPN overlays, one or
      when it is present more SRv6 Service SIDs
   are advertised with Route Type 1,2,3 and indicates that the Argument is encoded in
      the SID value (refer Section 5 for details).  Otherwise it carries
      the Argument part of 5.  The SRv6 SID when indicated as such by the SID
      Structure Sub-Sub-TLV.

   A Service SID enclosed SID(s)
   per Route Type are advertised in a SRv6 L2 L3/L2 Service TLV TLVs within the
   BGP Prefix-SID attribute is advertised along with Attribute.  Signaling of SRv6 Service SID(s) serves
   two purposes - first, it indicates that the BGP egress device
   supports SRv6 overlay and the BGP ingress device receiving this route
   MUST perform IPv6 encapsulation and optionally insert an SRH when
   required; second, it indicates the A-D route.  The
   behavior value of the Service SID thus signaled is entirely up SID(s) to be
   used in the
   originator of the advertisement. encapsulation.

   The SRv6 Service SID is used to signal
   Arg.FE2 SID argument for applicable End.DT2M SIDs.

4.1.2.  Per-EVI A-D route

   o  BGP next-hop: IPv6 address SHOULD be routable within the AS of an the egress
   PE
   o  Ethernet Tag ID: non-zero for VLAN-aware bundling service, EVPN
      VPWS and FXC

   o  MPLS Label: It is set to Implicit NULL when serves the SID Structure Sub-
      Sub-TLV is not present or when it is present dual purpose of providing reachability between
   ingress PE and indicates that egress PE while also encoding the Function is encoded in endpoint behavior.

   When the SID egress PE sets the next-hop to a value (refer Section 5 for
      details).  Otherwise it carries that is not covered
   by the Function part of SRv6 SID when
      indicated as such by Locator from which the SID Structure Sub-Sub-TLV.

   A Service SID enclosed in a SRv6 L2 Service TLV within the BGP
   Prefix-SID attribute SID is advertised along with allocated,
   then the A-D route.  The
   behavior of ingress PE SHOULD perform reachability check for the SRv6
   Service SID thus signaled is entirely up in addition to the
   originator of the advertisement.  In practice, the behavior would
   SHOULD be END.DX2, END.DX2V or END.DT2U.

4.2.  MAC/IP Advertisement BGP next-hop reachability procedures.

6.1.  Ethernet Auto-discovery route over SRv6 Core

   Ethernet Auto-Discovery (A-D) routes are Route Type 1 defined in
   [RFC7432] and may be used to achieve split horizon filtering, fast
   convergence and aliasing.  EVPN Route Type 2 1 is also used to advertise unicast traffic MAC+IP address
   reachability through MP-BGP to all other PEs in a given EVPN-
   VPWS as well as in EVPN
   instance. flexible cross-connect; mainly used to
   advertise point-to-point services ID.

   As a reminder, EVPN Route Type 2 1 is encoded as follows for SRv6 Core: follows:

                   +---------------------------------------+
                   |  RD (8 octets)                        |
                   +---------------------------------------+
                   |Ethernet Segment Identifier (10 octets)|
                   +---------------------------------------+
                   |  Ethernet Tag ID (4 octets)           |
                   +---------------------------------------+
                   |  MAC Address Length (1 octet)         |
                   +---------------------------------------+
                   |  MAC Address (6 octets)               |
                   +---------------------------------------+
                   |  IP Address Length (1 octet)          |
                   +---------------------------------------+
                   |  IP Address (0, 4, or 16 octets)      |
                   +---------------------------------------+
                   |  MPLS Label1 label (3 octets)                |
                   +---------------------------------------+
                   |  MPLS Label2 (0 or 3 octets)          |
                   +---------------------------------------+

   o  BGP next-hop: IPv6 address of an egress PE

   o  MPLS Label1: It is set to Implicit NULL when the SID Structure
      Sub-Sub-TLV is not present or when it is present and indicates
      that the Function is encoded in the SID value (refer Section 5 for
      details).  Otherwise it carries the Function part of SRv6 SID when
      indicated as such by the SID Structure Sub-Sub-TLV.

   o  MPLS Label2: It is set to Implicit NULL when the SID Structure
      Sub-Sub-TLV is not present or when it is present and indicates
      that the Function is encoded in the SID value (refer Section 5

6.1.1.  Per-ES A-D route

   Per-ES A-D route for
      details).  Otherwise it carries the Function part of SRv6 SID when
      indicated as such by the SID Structure Sub-Sub-TLV.

   Service SIDs enclosed in SRv6 L2 Service TLV and optionally in SRv6
   L3 Service TLV within the BGP SID attribute overlay is advertised along with
   the MAC/IP Advertisement route.

   Described below are different types of Route Type 2 advertisements. as follows:

   o  MAC/IP Advertisement route with MAC Only

      *  BGP next-hop: IPv6 address of egress PE

      *  MPLS Label1: It is set to Implicit NULL when the SID Structure
         Sub-Sub-TLV is not present or when it is present and indicates
         that the Function is encoded in the SID value (refer Section 5
         for details).  Otherwise it  BGP next-hop: IPv6 address of an egress PE

   o  Ethernet Tag ID: set as per [RFC7432]

   o  MPLS Label: set as per [RFC7432]

   o  ESI label extended community ESI label field: carries the Function Argument
      part of the SRv6 SID when indicated as such by ESI filtering approach is used along
      with the SID Structure Sub-Sub-TLV.

   o Transposition Scheme of encoding (Section 4) and
      otherwise set to Implicit NULL.

   A Service SID enclosed in a SRv6 L2 Service TLV within the BGP
   Prefix-SID attribute is advertised along with the A-D route.  The
   behavior of the Service SID thus signaled is entirely up to the
   originator of the advertisement.  In practice,  When ESI filtering approach is
   used, the behavior SHOULD Service SID is used to signal Arg.FE2 SID argument for
   applicable End.DT2M SIDs.  When local-bias approach is used, the
   Service SID MAY be END.DX2 or END.DT2U.

   o  MAC/IP Advertisement of value 0.

6.1.2.  Per-EVI A-D route with MAC+IP

      *

   Per-EVI A-D route for SRv6 overlay is advertised as follows:

   o  BGP next-hop: IPv6 address of an egress PE

      *  MPLS Label1: It is set to Implicit NULL when the SID Structure
         Sub-Sub-TLV is not present or when it is present

   o  Ethernet Tag ID: Set as per [RFC7432], [RFC8214] and indicates
         that the Function is encoded in the SID value(refer Section 5
         for details).  Otherwise it
      [I-D.ietf-bess-evpn-vpws-fxc]

   o  MPLS Label: carries the Function part of the SRv6 SID when indicated as such by the SID Structure Sub-Sub-TLV.

      *  MPLS Label2: It
      Transposition Scheme of encoding (Section 4) is used and otherwise
      set to Implicit NULL when the SID Structure
         Sub-Sub-TLV is not present or when it is present and indicates
         that the Function is encoded in the SID value (refer Section 5
         for details).  Otherwise it carries the Function part of SRv6
         SID when indicated as such by the SID Structure Sub-Sub-TLV.

   o  An L2 NULL.

   A Service SID enclosed in a SRv6 L2 Service TLV within the BGP
   Prefix-SID attribute is advertised along with the route.  In
      addition, an L3 Service SID enclosed in a SRv6 L3 Service TLV
      within the BGP SID attribute MAY also be advertised along with the A-D route.  The
   behavior of the Service SID(s) SID thus signaled is entirely up to the
   originator of the advertisement.  In practice,
      the behavior SHOULD be END.DX2 or END.DT2U for advertisement.  In practice, the L2 Service SID,
      and END.DT6/4 behavior is
   END.DX2, END.DX2V or END.DX6/4 for the L3 Service SID.

4.3.  Inclusive Multicast Ethernet Tag Route END.DT2U.

6.2.  MAC/IP Advertisement route over SRv6 Core

   EVPN Route Type 3 2 is used to advertise multicast unicast traffic MAC+IP address
   reachability
   information through MP-BGP to all other PEs in a given EVPN
   instance.

   As a reminder, EVPN Route Type 3 2 is encoded as follows for SRv6 core: follows:

                   +---------------------------------------+
                   |  RD (8 octets)                        |
                   +---------------------------------------+
                   |Ethernet Segment Identifier (10 octets)|
                   +---------------------------------------+
                   |  Ethernet Tag ID (4 octets)           |
                   +---------------------------------------+
                   |  IP  MAC Address Length (1 octet)         |
                   +---------------------------------------+
                   |  Originating Router's IP  MAC Address      |
                  |          (4 or 16 (6 octets)               |
                   +---------------------------------------+

   o  BGP next-hop: IPv6 address of egress PE

   PMSI Tunnel Attribute [RFC6514] MAY contain MPLS Implicit NULL label
   and Tunnel Type would be similar to that defined in EVPN Route Type 6
   i.e. Ingress replication route.

   The format of PMSI Tunnel Attribute is encoded as follows for SRv6
   Core:

                  +---------------------------------------+
                   |  Flag  IP Address Length (1 octet)          |
                   +---------------------------------------+
                   |  Tunnel Type (1 octet)  IP Address (0, 4, or 16 octets)      |
                   +---------------------------------------+
                   |  MPLS label Label1 (3 octet) octets)               |
                   +---------------------------------------+
                   |  Tunnel Identifier (variable)  MPLS Label2 (0 or 3 octets)          |
                   +---------------------------------------+

   o  Flag: zero value defined per [RFC7432]
   o  Tunnel Type: defined per [RFC6514]  BGP next-hop: IPv6 address of an egress PE

   o  MPLS label: Label1: Is associated with the SRv6 L2 Service TLV.  It
      carries the Function part of the SRv6 SID when the Transposition
      Scheme of encoding (Section 4) is used and otherwise set to
      Implicit NULL when NULL.

   o  MPLS Label2: Is associated with the SRv6 L3 Service TLV.  It
      carries the Function part of the SRv6 SID Structure Sub-
      Sub-TLV is not present or when it the Transposition
      Scheme of encoding (Section 4) is present used and indicates that otherwise set to
      Implicit NULL.

   Service SIDs enclosed in SRv6 L2 Service TLV and optionally in SRv6
   L3 Service TLV within the Function BGP Prefix-SID attribute is encoded in advertised
   along with the MAC/IP Advertisement route.

   Described below are different types of Route Type 2 advertisements.

6.2.1.  MAC/IP Advertisement route with MAC Only

   o  MPLS Label1: Is associated with the SID value (refer Section 5 for
      details).  Otherwise it SRv6 L2 Service TLV.  It
      carries the Function part of the SRv6 SID when
      indicated as such by the SID Structure Sub-Sub-TLV.

   o  Tunnel Identifier: IP address Transposition
      Scheme of egress PE encoding (Section 4) is used and otherwise set to
      Implicit NULL.

   A Service SID enclosed in a SRv6 L2 Service TLV within the BGP
   Prefix-SID attribute is advertised along with the route.  The
   behavior of the Service SID thus signaled, signaled is entirely up to the
   originator of the advertisement.  In practice, the behavior of the
   SRv6 SID is as follows:

   o
   END.DX2 or END.DT2M behavior END.DT2U.

6.2.2.  MAC/IP Advertisement route with MAC+IP

   o  The ESI Filtering argument (Arg.FE2) of  MPLS Label1: Is associated with the SRv6 L2 Service SID carried
      along with EVPN Route Type 1 route SHOULD be merged together with TLV.  It
      carries the applicable End.DT2M SID Function part of Type 3 route advertised by remote
      PE by doing a bitwise logical-OR operation to create a single the SRv6 SID
      on when the ingress PE for Split-horizon Transposition
      Scheme of encoding (Section 4) is used and other filtering
      mechanisms.  Details otherwise set to
      Implicit NULL.

   o  MPLS Label2: Is associated with the SRv6 L3 Service TLV.  It
      carries the Function part of filtering mechanisms are described in
      [RFC7432].

4.4.  Ethernet Segment route over the SRv6 Core

   An Ethernet Segment route i.e. EVPN Route Type 4 SID when the Transposition
      Scheme of encoding (Section 4) is encoded as
   follows for used and otherwise set to
      Implicit NULL.

   An L2 Service SID enclosed in a SRv6 core:

                  +---------------------------------------+
                  |  RD (8 octets)                        |
                  +---------------------------------------+
                  |  Ethernet Tag ID (4 octets)           |
                  +---------------------------------------+
                  |  IP Address Length (1 octet)          |
                  +---------------------------------------+
                  |  Originating Router's IP Address      |
                  |          (4 or 16 octets)             |
                  +---------------------------------------+

   o L2 Service TLV within the BGP next-hop: IPv6 address of egress PE
   Prefix-SID attribute is advertised along with the route.  In
   addition, an L3 Service SID enclosed in a SRv6 L3 Service TLVs TLV within
   the BGP SID Prefix-SID attribute are not MAY also be advertised along with this the
   route.  The processing behavior of the route has not changed - it
   remains as described in [RFC7432].

4.5.  IP prefix route Service SID(s) thus signaled is entirely
   up to the originator of the advertisement.  In practice, the behavior
   is END.DX2 or END.DT2U for the L2 Service SID, and END.DT6/4 or
   END.DX6/4 for the L3 Service SID.

6.3.  Inclusive Multicast Ethernet Tag Route over SRv6 Core

   EVPN Route Type 5 3 is used to advertise IP address multicast traffic reachability
   information through MP-BGP to all other PEs in a given EVPN instance.  IP address
   may include host IP prefix or any specific subnet.

   As a reminder, EVPN Route Type 5 3 is encoded as follows for SRv6 core: follows:

                  +---------------------------------------+
                  |  RD (8 octets)                        |
                  +---------------------------------------+
                  |Ethernet Segment Identifier (10 octets)|
                  +---------------------------------------+
                  |  Ethernet Tag ID (4 octets)           |
                  +---------------------------------------+
                  |  IP Prefix Address Length (1 octet)          |
                  +---------------------------------------+
                  |  Originating Router's IP Prefix (4 or 16 octets) Address      |
                  +---------------------------------------+
                  |  GW IP Address          (4 or 16 octets)             |
                  +---------------------------------------+
                  |  MPLS Label (3 octets)                |
                  +---------------------------------------+

   o  BGP next-hop: IPv6 address of egress PE

   o  MPLS Label: It

   PMSI Tunnel Attribute [RFC6514] is set used to Implicit NULL when the SID Structure Sub-
      Sub-TLV is not present or when it is present and indicates that identify the Function P-tunnel used
   for sending BUM traffic.  The format of PMSI Tunnel Attribute is
   encoded in the SID value (refer Section 5 as follows for
      details).  Otherwise it SRv6 Core:

                  +---------------------------------------+
                  |  Flag (1 octet)                       |
                  +---------------------------------------+
                  |  Tunnel Type (1 octet)                |
                  +---------------------------------------+
                  |  MPLS label (3 octet)                 |
                  +---------------------------------------+
                  |  Tunnel Identifier (variable)         |
                  +---------------------------------------+

   o  Flag: zero value defined per [RFC7432]

   o  Tunnel Type: defined per [RFC6514]

   o  MPLS label: It carries the Function part of the SRv6 SID when
      indicated as such by
      ingress replication is used and the SID Structure Sub-Sub-TLV.

   SRv6 Service SID Transposition Scheme of
      encoding (Section 4) is encoded used and otherwise it is set as part defined in
      [RFC6514]

   o  Tunnel Identifier: IP address of the egress PE

   A Service SID enclosed in a SRv6 L3 L2 Service TLV. TLV within the BGP
   Prefix-SID attribute is advertised along with the route.  The
   function
   behavior of the SRv6 Service SID thus signaled, is entirely up to the
   originator of the advertisement.  In practice, the behavior may SHOULD be End.DT4/6 or
   End.DX4/6.

4.6.  EVPN multicast routes (Route Types 6, 7, 8) over of the
   SRv6 core

   These routes do not require SID is as follows:

   o  END.DT2M behavior.

   o  When ESI-based filtering is used for Multi-Homing or E-Tree
      procedures, the advertisement ESI Filtering argument (Arg.FE2) of SRv6 the Service TLVs
      SID carried along with them.  Similar to EVPN Route Type 4, 1 route SHOULD be merged
      together with the BGP Nexthop is
   equal applicable End.DT2M SID of Type 3 route
      advertised by remote PE by doing a bitwise logical-OR operation to
      create a single SID on the IPv6 address of egress ingress PE.  More details may be added in
   future revisions  Details of this document.

5.  Encoding SRv6 SID information

   The SRv6 Service SID(s) split-horizon
      ESI-based filtering mechanisms for a BGP Service Prefix multihoming are carried described in the
   SRv6 Services TLVs of the BGP Prefix-SID Attribute.

   For certain types
      [RFC7432].  Details of BGP Services like L3VPN where a per-VRF SID
   allocation is used (i.e.  End.DT4 or End.DT6 behaviors), the same SID
   is shared across multiple NLRIs thus providing efficient packing.
   However, filtering mechanisms for certain other types of BGP Services like EVPN VPWS where
   a per-PW SID allocation is required (i.e.  End.DX2 behavior), each
   NLRI would have its own unique SID there by resulting in inefficient
   packing.

   To achieve efficient packing, this document allows flexibility in the
   advertisement of the SRv6 Service SID either as a whole Leaf-originated
      BUM traffic in the SRv6
   Services TLVs or the encoding of only the common parts of the SRv6
   SID (e.g.  Locator parts) EVPN E-Tree services are provided in [RFC8317].

   o  When "local-bias" is used as the SRv6 Services TLVs and encoding Multi-Homing split-horizon
      method, the
   variable (e.g.  Function and Argument parts) in ESI Filtering argument SHOULD NOT be merged with the existing label
   fields specific to that service encoding.  The SRv6
      corresponding End.DT2M SID Structure
   Sub-Sub-TLV describes on the sizes ingress PE.  Details of the parts
      "local-bias" procedures are described in [RFC8365].

   The setup of multicast trees for use as P-tunnels is outside the SRv6 SID.  It
   also indicate offset
   scope of variable part and its length in this document.

6.4.  Ethernet Segment route over SRv6 SID
   value. Core

   As a reminder, an example, for the Ethernet Segment route i.e. EVPN VPWS service prefix described in section
   4.1.2, the function part Route Type 4 is
   encoded as follows:

                  +---------------------------------------+
                  |  RD (8 octets)                        |
                  +---------------------------------------+
                  |  Ethernet Tag ID (4 octets)           |
                  +---------------------------------------+
                  |  IP Address Length (1 octet)          |
                  +---------------------------------------+
                  |  Originating Router's IP Address      |
                  |          (4 or 16 octets)             |
                  +---------------------------------------+

   o  BGP next-hop: IPv6 address of egress PE

   SRv6 Service TLVs within BGP Prefix-SID attribute are not advertised
   along with this route.  The processing of the route has not changed -
   it remains as described in [RFC7432].

6.5.  IP prefix route over SRv6 SID Core

   EVPN Route Type 5 is encoded used to advertise IP address reachability
   through MP-BGP to all other PEs in the a given EVPN instance.  IP address
   may include host IP prefix or any specific subnet.

   As a reminder, EVPN Route Type 5 is encoded as follows:

                  +---------------------------------------+
                  |  RD (8 octets)                        |
                  +---------------------------------------+
                  |Ethernet Segment Identifier (10 octets)|
                  +---------------------------------------+
                  |  Ethernet Tag ID (4 octets)           |
                  +---------------------------------------+
                  |  IP Prefix Length (1 octet)           |
                  +---------------------------------------+
                  |  IP Prefix (4 or 16 octets)           |
                  +---------------------------------------+
                  |  GW IP Address (4 or 16 octets)       |
                  +---------------------------------------+
                  |  MPLS Label
   field (3 octets)                |
                  +---------------------------------------+

   o  BGP next-hop: IPv6 address of the NLRI and the SID value in the SRv6 Services TLV egress PE
   o  MPLS Label: It carries
   only the locator parts with Function part of the SRv6 SID Structure Sub-Sub-TLV
   included.  The SRv6 SID Structure sub-sub-TLV defines the lengths of
   locator block, locator node and function parts (arguments are not
   applicable for the End.DX2 behavior).  Transposition Offset indicates when the bit position and
      Transposition Length indicates the number of
   bits that are being taken out Scheme of the SID encoding (Section 4) is used and put into label field.

   In yet another example, for the EVPN Per-ES A-D route described in
   section 4.1.1, only the argument of the SID needs otherwise
      set to be signaled.
   This argument part of the Implicit NULL.

   SRv6 Service SID MAY be Transposed in the ESI Label
   field of the ESI Label Extended Community and the SID value in the
   SRv6 Services TLV is set to 0 with encoded as part of the SRv6 SID Structure Sub-Sub-TLV
   included. L3 Service TLV.  The SRv6 SID Structure sub-sub-TLV defines the lengths of
   locator block, locator node,
   function and argument parts.  The offset
   and length of argument part SID value moved to label field is set in
   Transpostion offset and length of the SRv6 SID structure TLV.  The receiving
   router is then able entirely up to put together the entire SRv6 Service SID (e.g.
   for originator of the End.DT2M behavior) placing
   advertisement.  In practice, the label value received in behavior is End.DT4/6 or End.DX4/6.

6.6.  EVPN multicast routes (Route Types 6, 7, 8) over SRv6 core

   These routes do not require the
   ESI Label field advertisement of the Per-ES A-D route into the correct
   transposition offset and length in the SRv6 SID Service TLVs
   along with the End.DT2M
   behavior received for a them.  Similar to EVPN Route Type 3 value.

6. 4, the BGP Nexthop is
   equal to the IPv6 address of egress PE.

7.  Implementation Status

   The [I-D.matsushima-spring-srv6-deployment-status] describes the
   current deployment and implementation status of SRv6 which also
   includes the BGP services over SRv6 as specified in this document.

7.

8.  Error Handling

   In case of any errors encountered while processing SRv6 Service TLVs,
   the details of the error SHOULD be logged for further analysis.

   If multiple instances of SRv6 L3 Service TLV is encountered, all but
   the first instance MUST be ignored.

   If multiple instances of SRv6 L2 Service TLV is encountered, all but
   the first instance MUST be ignored.

   An SRv6 Service TLV is considered malformed in the following cases:

   o  the TLV Length is less than 1

   o  the TLV Length is inconsistent with the length of BGP SID Prefix-SID
      attribute

   o  atleast one of the constituent Sub-TLVs is malformed

   An SRv6 Service Sub-TLV is considered malformed in the following
   cases:

   o  the Sub-TLV Length is inconsistent with the length of the
      enclosing SRv6 Service TLV

   An SRv6 SID Information Sub-TLV is considered malformed in the
   following cases:

      *  the Sub-TLV Length is less than 21

      *  the Sub-TLV Length is inconsistent with the length of the
         enclosing SRv6 Service TLV

      *  atleast one of the constituent Sub-Sub-TLVs is malformed

   An SRv6 Service Data Sub-sub-TLV is considered malformed in the
   following cases:

   o  the Sub-Sub-TLV Length is inconsistent with the length of the
      enclosing SRv6 service Sub-TLV

   Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because
   its Type is unrecognized.

   Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because
   of failing any semantic validation of its Value field.

   The BGP Prefix-SID attribute is considered malformed if it contains
   atleast one constituent SRv6 Service TLV that is malformed.  In such
   cases, the attribute MUST be discarded [RFC7606]and not propagated
   further.  Note that if a path whose BGP Prefix-SID attribute is
   discarded in this manner is selected as the best path to be installed
   in the RIB, traffic forwarding for the corresponding prefix may be
   affected.  Implementations MAY choose to make such paths less
   preferable or even ineligible during the selection of best path for
   the corresponding prefix.

   SRv6 SID value in SRv6 Service Sub-TLV is invalid when SID Structure
   Sub-Sub-TLV is present and transposition length is greater than 24 or
   addition of transposition offset and length is greater than 128.
   Path pointing to such Prefix-SID Attribute should be ineligible
   during the selection of best path for the corresponding prefix.

   A BGP speaker receiving a path containing BGP Prefix-SID Attribute
   with one or more SRv6 Service TLVs observes the following rules when
   advertising the received path to other peers:

   o  if the nexthop is unchanged during advertisement, the SRv6 Service
      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.

   o  if the nexthop is changed during advertisement, not considered malformed because
   of failing any unrecognized
      Sub-TLVs and Sub-Sub-TLVs semantic validation of its Value field.

   SRv6 overlay service requires Service SID for forwarding.  The treat-
   as-withdraw action [RFC7606] MUST NOT be propagated.

   o  if the nexthop performed when at least one
   malformed SRV6 Service TLV is changed during advertisement, present in the TLVs, Sub-TLVs BGP Prefix-SID
   attribute.

   SRv6 SID value in SRv6 Service Sub-TLV is invalid when SID Structure
   Sub-Sub-TLV transposition length is greater than 24 or addition of
   transposition offset and Sub-Sub-TLVs SHOULD length is greater than 128.  Path having
   such Prefix-SID Attribute should be re-originated if appropriate, and not
      merely propagated unchanged.  The interpretation of ineligible during the meaning of
      re-origination versus propagation is a matter selection
   of local
      implementation.

8. best path for the corresponding prefix.

9.  IANA Considerations
8.1.

9.1.  BGP Prefix-SID TLV Types registry

   This document defines two new TLV Types of the BGP Prefx-SID Prefix-SID
   attribute.  IANA is requested to assign Type values in the registry
   "BGP Prefix-SID TLV Types" as follows:

       Value     Type                    Reference
       --------------------------------------------
       [TBD1]
       4       Deprecated              <this document>
       TBD1    SRv6 L3 Service TLV     <this document>
       [TBD2]
       TBD2    SRv6 L2 Service TLV     <this document>

   IANA is also requested

   The value 4 previously corresponded to reserve the following Type value.  This SRv6-VPN SID TLV, which
   was
   used specified in some implementations of previous versions of this draft.

       Value     Type                    Reference
       --------------------------------------------
         4       Reserved                <this document>

8.2. document and used by early
   implementations of this specification.  It was deprecated and
   replaced by the SRv6 L3 Service and SRv6 L2 Service TLVs.

9.2.  SRv6 Service Sub-TLV Types registry

   IANA is requested to create and maintain a new registry called "SRv6
   Service Sub-TLV Types".  The allocation policy for this registry is:

      0 : Reserved
      1-127 : IETF Review
      128-254 : First Come First Served
      255 : Reserved

   The following Sub-TLV Types are defined in this document:

      Value     Type                            Reference
       ----------------------------------------------------
       1         SRv6 SID Information Sub-TLV    <this document>

8.3.

9.3.  SRv6 Service Data Sub-Sub-TLV Types registry

   IANA is requested to create and maintain a new registry called "SRv6
   Service Data Sub-Sub-TLV Types".  The allocation policy for this
   registry is:

      0 : Reserved
      1-127 : IETF Review
      128-254 : First Come First Served
      255 : Reserved

   The following Sub-Sub-TLV Types are defined in this document:

      Value     Type                              Reference
       ----------------------------------------------------
       1         SRv6 SID Structure Sub-Sub-TLV    <this document>

9.

10.  Security Considerations

   This document introduces no new security considerations beyond those
   already specified in [RFC4271] and [RFC8277].

10.  Conclusions

   This [RFC4271].

11.  Acknowledgments

   The authors of this document proposes extensions to the BGP would like to allow advertising
   certain attributes thank Stephane Litkowski,
   Rishabh Parekh and functionalities related to SRv6.

11. Xiejingrong for their comments and review of this
   document.

12.  Contributors

   Satoru Matsushima
   SoftBank

   Email: satoru.matsushima@g.softbank.co.jp

   Dirk Steinberg
   Steinberg Consulting

   Email: dws@steinberg.net

   Daniel Bernier
   Bell Canada

   Email: daniel.bernier@bell.ca

   Daniel Voyer
   Bell Canada

   Email: daniel.voyer@bell.ca

   Jonn Leddy
   Individual

   Email: john@leddy.net

   Swadesh Agrawal
   Cisco

   Email: swaagraw@cisco.com

   Patrice Brissette
   Cisco

   Email: pbrisset@cisco.com

   Ali Sajassi
   Cisco

   Email: sajassi@cisco.com

   Bart Peirens
   Proximus
   Belgium

   Email: bart.peirens@proximus.com
   Darren Dukes
   Cisco

   Email: ddukes@cisco.com

   Pablo Camarilo
   Cisco

   Email: pcamaril@cisco.com

   Shyam Sethuram
   Cisco

   Email: shyam.ioml@gmail.com

   Zafar Ali
   Cisco

   Email: zali@cisco.com

   Ketan Talaulikar
   Cisco

   Email: ketant@cisco.com

13.  References

11.1.

13.1.  Normative References

   [I-D.filsfils-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., Hegde, S.,
              daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
              b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
              Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste,
              J., Clad, F., and K. Raza, "Segment Routing Policy
              Architecture", draft-filsfils-spring-segment-routing-
              policy-06 (work in progress), May 2018.

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-26 (work in
              progress), October 2019.

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6 Network Programming",
              draft-ietf-spring-srv6-network-programming-05 (work in
              progress), October 2019.

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

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
              <https://www.rfc-editor.org/info/rfc4456>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

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

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

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

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

11.2.  Informative References

   [I-D.ietf-bess-evpn-igmp-mld-proxy]
              Sajassi, A., Thoria, S., Patel, K., Drake, J., and W. Lin,
              "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp-
              mld-proxy-04 (work in progress), September 2019.

   [I-D.ietf-bess-evpn-prefix-advertisement]
              Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
              Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf-
              bess-evpn-prefix-advertisement-11 (work in progress), May
              2018.

   [I-D.ietf-idr-bgp-prefix-sid]
              Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A.,
              and H. Gredler, "Segment Routing W., and A.
              Sajassi, "IP Prefix SID extensions for
              BGP", draft-ietf-idr-bgp-prefix-sid-27 Advertisement in EVPN", draft-ietf-
              bess-evpn-prefix-advertisement-11 (work in progress),
              June May
              2018.

   [I-D.ietf-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Mattes,

   [I-D.ietf-bess-evpn-vpws-fxc]
              Sajassi, A., Brissette, P., Rosen, E., Jain,
              D., and S. Uttaro, J., Drake, J., Lin, "Advertising Segment Routing Policies in
              BGP", draft-ietf-idr-segment-routing-te-policy-07
              W., Boutros, S., and J. Rabadan, "EVPN VPWS Flexible
              Cross-Connect Service", draft-ietf-bess-evpn-vpws-fxc-01
              (work in progress), July June 2019.

   [I-D.ietf-isis-segment-routing-extensions]
              Previdi,

   [I-D.ietf-bess-rfc5549revision]
              Litkowski, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
              Gredler, H., Agrawal, S., ananthamurthy, k., and B. Decraene, "IS-IS Extensions for
              Segment Routing", draft-ietf-isis-segment-routing-
              extensions-25 K.
              Patel, "Advertising IPv4 Network Layer Reachability
              Information with an IPv6 Next Hop", draft-ietf-bess-
              rfc5549revision-03 (work in progress), May 2019.

   [I-D.matsushima-spring-srv6-deployment-status]
              Matsushima, S., February 2020.

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Ali, Z., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6
              Implementation and Deployment Status", draft-matsushima-
              spring-srv6-deployment-status-02 Network Programming",
              draft-ietf-spring-srv6-network-programming-10 (work in
              progress),
              October 2019. February 2020.

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

   [RFC2545]  Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
              Extensions for IPv6 Inter-Domain Routing", RFC 2545,
              DOI 10.17487/RFC2545, March 1999,
              <https://www.rfc-editor.org/info/rfc2545>.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
              <https://www.rfc-editor.org/info/rfc3032>.

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

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
              <https://www.rfc-editor.org/info/rfc4456>.

   [RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
              "BGP-MPLS IP Virtual Private Network (VPN) Extension for
              IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
              <https://www.rfc-editor.org/info/rfc4659>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC5549]  Le Faucheur, F. and E.

   [RFC6514]  Aggarwal, R., Rosen, "Advertising IPv4 Network
              Layer Reachability Information with an IPv6 Next Hop", E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

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

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 5549, 7606, DOI 10.17487/RFC5549, May 2009,
              <https://www.rfc-editor.org/info/rfc5549>. 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>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8214]  Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
              Rabadan, "Virtual Private Wire Service Support in Ethernet
              VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
              <https://www.rfc-editor.org/info/rfc8214>.

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

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

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

Appendix A.  Contributors

   Satoru Matsushima
   SoftBank

   Email: satoru.matsushima@g.softbank.co.jp

   Dirk Steinberg
   Steinberg Consulting

   Email: dws@steinberg.net

   Daniel Bernier
   Bell Canada

   Email: daniel.bernier@bell.ca

   Daniel Voyer
   Bell Canada

   Email: daniel.voyer@bell.ca

   Jonn Leddy
   Individual

   Email: john@leddy.net

   Swadesh Agrawal
   Cisco

   Email: swaagraw@cisco.com

   Patrice Brissette
   Cisco

   Email: pbrisset@cisco.com
   Ali Sajassi
   Cisco

   Email: sajassi@cisco.com

   Bart Peirens
   Proximus
   Belgium

   Email: bart.peirens@proximus.com

   Darren Dukes
   Cisco

   Email: ddukes@cisco.com

   Pablo Camarilo
   Cisco

   Email: pcamaril@cisco.com

   Shyam Sethuram
   Cisco

   Email: shyam.ioml@gmail.com

   Zafar Ali
   Cisco

   Email: zali@cisco.com

   Ketan Talaulikar
   Cisco

   Email: ketant@cisco.com

   [RFC8669]  Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
              A., and H. Gredler, "Segment Routing Prefix Segment
              Identifier Extensions for BGP", RFC 8669,
              DOI 10.17487/RFC8669, December 2019,
              <https://www.rfc-editor.org/info/rfc8669>.

13.2.  Informative References

   [I-D.ietf-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
              Rosen, E., Jain, D., and S. Lin, "Advertising Segment
              Routing Policies in BGP", draft-ietf-idr-segment-routing-
              te-policy-08 (work in progress), November 2019.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", draft-
              ietf-spring-segment-routing-policy-06 (work in progress),
              December 2019.

   [I-D.matsushima-spring-srv6-deployment-status]
              Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6
              Implementation and Deployment Status", draft-matsushima-
              spring-srv6-deployment-status-05 (work in progress),
              January 2020.

Authors' Addresses

   Gaurav Dawra (editor)
   LinkedIn
   USA

   Email: gdawra.ietf@gmail.com

   Clarence Filsfils
   Cisco Systems
   Belgium

   Email: cfilsfil@cisco.com
   Robert Raszuk
   Bloomberg LP
   USA

   Email: robert@raszuk.net

   Bruno Decraene
   Orange
   France

   Email: bruno.decraene@orange.com

   Shunwan Zhuang
   Huawei Technologies
   China

   Email: zhuangshunwan@huawei.com

   Jorge Rabadan
   Nokia
   USA

   Email: jorge.rabadan@nokia.com