BESS Working Group
Internet Engineering Task Force (IETF) G. Dawra, Ed.
Internet-Draft
Request for Comments: 9252 LinkedIn
Intended status:
Category: Standards Track K. Talaulikar, Ed.
Expires: September 23, 2022
ISSN: 2070-1721 Cisco Systems
R. Raszuk
NTT Network Innovations
B. Decraene
Orange
S. Zhuang
Huawei Technologies
J. Rabadan
Nokia
March 22,
June 2022
SRv6 BGP based
Segment Routing over IPv6 (SRv6) BGP-Based Overlay Services
draft-ietf-bess-srv6-services-15
Abstract
This document defines procedures and messages for SRv6-based BGP
services
services, including L3VPN, EVPN, Layer 3 Virtual Private Network (L3VPN), Ethernet
VPN (EVPN), and Internet services. It builds on
RFC4364 "BGP/MPLS IP Virtual
Private Networks (VPNs)" (RFC 4364) and RFC7432 "BGP MPLS-Based Ethernet VPN". VPN"
(RFC 7432).
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 an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of six months RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 September 23, 2022.
https://www.rfc-editor.org/info/rfc9252.
Copyright Notice
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Simplified Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. SRv6 Services TLVs . . . . . . . . . . . . . . . . . . . . . 4
3. SRv6 Service Sub-TLVs . . . . . . . . . . . . . . . . . . . . 5
3.1. SRv6 SID Information Sub-TLV . . . . . . . . . . . . . . 6
3.2. SRv6 Service Data Sub-Sub-TLVs . . . . . . . . . . . . . 8
3.2.1. SRv6 SID Structure Sub-Sub-TLV . . . . . . . . . . . 8
4. Encoding SRv6 SID Information . . . . . . . . . . . . . . . . 11
5. BGP based BGP-Based L3 Service over SRv6 . . . . . . . . . . . . . . . 12
5.1. IPv4 VPN Over over SRv6 Core . . . . . . . . . . . . . . . . . 13
5.2. IPv6 VPN Over over SRv6 Core . . . . . . . . . . . . . . . . . 13
5.3. Global IPv4 over SRv6 Core . . . . . . . . . . . . . . . 14
5.4. Global IPv6 over SRv6 Core . . . . . . . . . . . . . . . 14
6. BGP based BGP-Based Ethernet VPN (EVPN) over SRv6 . . . . . . . . . . . 14
6.1. Ethernet Auto-discovery Auto-Discovery Route over SRv6 Core . . . . . . 16
6.1.1. Ethernet A-D per ES Route . . . . . . . . . . . . . . 16
6.1.2. Ethernet A-D per EVI Route . . . . . . . . . . . . . 17
6.2. MAC/IP Advertisement Route over SRv6 Core . . . . . . . . 17
6.2.1. MAC/IP Advertisement Route with MAC Only . . . . . . 19
6.2.2. MAC/IP Advertisement Route with MAC+IP . . . . . . . 19
6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core . . 20
6.4. Ethernet Segment Route over SRv6 Core . . . . . . . . . . 21
6.5. IP Prefix Route over SRv6 Core . . . . . . . . . . . . . 22
6.6. EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6
Core . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23
9.
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1.
8.1. BGP Prefix-SID TLV Types Registry . . . . . . . . . . . . 24
9.2.
8.2. SRv6 Service Sub-TLV Types Registry . . . . . . . . . . . 25
9.3.
8.3. SRv6 Service Data Sub-Sub-TLV Types Registry . . . . . . 25
9.4.
8.4. BGP SRv6 Service SID Flags Registry . . . . . . . . . . . 26
9.5. Subsequent Address Family Identifiers (SAFI) Parameters
8.5. SAFI Values Registry . . . . . . . . . . . . . . . . . . . . . . . . 26
10.
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10.1. BGP Session
9.1. Considerations Related to BGP Sessions
9.2. Considerations . . . . . . . . . . . 26
10.2. Related to BGP Services Related
9.3. Considerations . . . . . . . . . . 26
10.3. Related to SR over IPv6 Data Plane Related Considerations . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
13.
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1.
10.1. Normative References . . . . . . . . . . . . . . . . . . 30
13.2.
10.2. Informative References . . . . . . . . . . . . . . . . . 32
Acknowledgements
Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
SRv6 refers to Segment Routing instantiated on the IPv6 dataplane data plane
[RFC8402].
BGP is used to advertise the reachability of prefixes of a particular
service from an egress PE Provider Edge (PE) to ingress PE nodes.
SRv6 based
SRv6-based BGP services refers refer to the Layer-3 Layer 3 (L3) and Layer-2 Layer 2 (L2)
overlay services with BGP as the control plane and SRv6 as dataplane. the data
plane. This document defines procedures and messages for SRv6-based
BGP services services, including L3VPN, EVPN, and Internet services. It
builds on [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)" [RFC4364] and [RFC7432]
"BGP MPLS-Based Ethernet VPN". VPN" [RFC7432].
SRv6 SID refers to an SRv6 Segment Identifier Identifier, as defined in
[RFC8402].
SRv6 Service SID refers to an SRv6 SID associated with one of the
service-specific SRv6 Endpoint behaviors on the advertising Provider
Edge (PE) PE
router, such as (but not limited to), to) End.DT (Table lookup (table look up in a VRF) VPN
Routing and Forwarding (VRF)) or End.DX (cross-connect to a nexthop) next hop)
behaviors in the case of Layer-3 Virtual Private Network (L3VPN) service L3VPN service, as defined in [RFC8986].
This document describes how existing BGP messages between PEs may
carry SRv6 Service SIDs to interconnect PEs and form VPNs.
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
Provider Edge (PE).
PE. The underlay between the PEs only needs to support plain IPv6
forwarding [RFC8200].
To provide SRv6 service in conjunction with an underlay SLA Service Level
Agreement (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]
[IDR-SEGMENT-ROUTING-TE-POLICY] for steering of flows for those routes routes,
as specified in section Section 8 of
[I-D.ietf-spring-segment-routing-policy]. [IGMP-MLD-EVPN]. The ingress PE
encapsulates the payload packet in an outer IPv6 header with the SR
Policy segment list of SR policy associated with the related SLA along with the
SRv6 Service SID associated with the route using the Segment Routing
Header (SRH) [RFC8754]. The underlay nodes whose SRv6 SID's SIDs are part
of the SRH segment list MUST support the SRv6 data plane.
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 use of the BGP Prefix-SID attribute
[RFC8669] to carry SRv6 SIDs and their associated information with
the BGP address-families address families that are listed further in this section.
The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-
SID Attribute 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 SRv6-based L3
services. It corresponds to the equivalent functionality provided
by an MPLS Label when received with a Layer 3 service route route, as
defined in [RFC4364] [RFC4659] [RFC8950] [RFC4364], [RFC4659], [RFC8950], and [RFC9136]. Some
SRv6 Endpoint behaviors which that may be encoded, but not limited to,
are End.DX4, End.DT4, End.DX6, End.DT6, and End.DT46.
o
SRv6 L2 Service TLV:
This TLV encodes Service SID information for
SRv6 based SRv6-based L2
services. It corresponds to the equivalent functionality provided
by an MPLS Label1 for Ethernet VPN (EVPN)
Route-Types Route Types, as defined
in [RFC7432]. Some SRv6 Endpoint behaviors
which that may be encoded, encoded
are, but not limited to, are End.DX2, End.DX2V, End.DT2U, and
End.DT2M.
When an egress PE is enabled for BGP Services over the SRv6 data-plane, data
plane, it signals one or more SRv6 Service SIDs enclosed in an SRv6
Service TLV(s) within the BGP Prefix-SID Attribute attribute attached to MP-BGP NLRIs
Multiprotocol BGP (MP-BGP) Network Layer Reachability Information
(NLRI) defined in [RFC4760] [RFC4659] [RFC8950] [RFC7432] [RFC4364]
[RFC9136] [RFC4760], [RFC4659], [RFC8950], [RFC7432],
[RFC4364], and [RFC9136], where applicable applicable, as described in Section Sections
5 and Section 6.
The support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6
is outside the scope of this document.
The following depicts the SRv6 Service TLVs encoded in the BGP
Prefix-SID Attribute: 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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6 Service TLVs
o
TLV Type (1 octet):
This field is assigned values from the IANA
registry IANA's "BGP Prefix-SID TLV Types".
Types" subregistry. It is set to 5 for the SRv6 L3 Service TLV.
It is set to 6 for the SRv6 L2 Service TLV.
o
TLV Length (2 octets): Specifies
This field specifies the total length, in octets, of the TLV
Value.
o
RESERVED (1 octet):
This field is reserved; it MUST be set to 0 by the sender and
ignored by the receiver.
o
SRv6 Service Sub-TLVs (variable):
This field contains SRv6 Service
related Service-related information and is
encoded as an unordered list of Sub-
TLVs Sub-TLVs whose format is described
below.
A BGP speaker receiving a route containing the BGP Prefix-SID Attribute
attribute with one or more SRv6 Service TLVs observes the following
rules when advertising the received route to other peers:
o if
* If the nexthop next hop is unchanged during the 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 TLV, Sub-TLV, or Sub-Sub-TLV MUST be propagated
unchanged.
o if
* If the nexthop next hop is changed, the TLVs, Sub-TLVs, and Sub-Sub-TLVs
SHOULD be updated with the locally allocated SRv6 SID information.
Any unrecognized 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-TLV //
| Type | Length | value Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SRv6 Service Sub-TLVs
o
SRv6 Service Sub-TLV Type (1 octet): Identifies
This field identifies the type of SRv6 service information. It is
assigned values from the IANA Registry IANA's "SRv6 Service Sub-TLV Types".
o Types"
subregistry.
SRv6 Service Sub-TLV Length (2 octets): Specifies
This field specifies the total length, in octets, of the Sub-TLV
Value field.
o
SRv6 Service Sub-TLV Value (variable): Contains
This field contains data specific to the Sub-TLV Type. In
addition to fixed-length data, it contains other properties of the
SRv6 Service encoded as a set of SRv6 Service Data Sub-Sub-TLVs
whose format is described in Section 3.2 below.
3.1. SRv6 SID Information Sub-TLV
SRv6 Service Sub-TLV Type 1 is assigned for the SRv6 SID Information Sub-
TLV.
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 | RESERVED1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 SID Value (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Svc SID Flags | SRv6 Endpoint Behavior | RESERVED2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service Data Sub-Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SRv6 SID Information Sub-TLV
o
SRv6 Service Sub-TLV Type (1 octet):
This field is set to 1 to represent the SRv6 SID Information Sub-TLV.
o Sub-
TLV.
SRv6 Service Sub-TLV Length (2 octets):
This field contains the total length, in octets, of the Value
field of the Sub-TLV.
o
RESERVED1 (1 octet):
This field MUST be set to 0 by the sender and ignored by the
receiver.
o
SRv6 SID Value (16 octets): Encodes
This field encodes an SRv6 SID SID, as defined in
[RFC8986]
o [RFC8986].
SRv6 Service SID Flags (1 octet): Encodes
This field encodes SRv6 Service SID Flags - -- none are currently
defined. It SHOULD be set to 0 by the sender and any unknown
flags MUST be ignored by the receiver.
o
SRv6 Endpoint Behavior (2 octets): Encodes
This field encodes the SRv6 Endpoint behavior codepoint value that
is associated with the SRv6 SID. The codepoints used are from the
IANA's "SRv6 Endpoint Behavior" registry Behaviors" subregistry under the IANA "Segment
Routing" parameters registry that was introduced by [RFC8986]. The opaque
endpoint behavior (i.e., value 0xFFFF) MAY be used when the
advertising router wishes to abstract the actual behavior of it's its
locally instantiated SRv6 SID.
o
RESERVED2 (1 octet):
This field MUST be set to 0 by the sender and ignored by the
receiver.
o
SRv6 Service Data Sub-Sub-TLV Value (variable): Used
This field is used to advertise properties of the SRv6 SID. It is
encoded as a set of SRv6 Service Data Sub-Sub-TLVs.
The choice of SRv6 Endpoint behavior of the SRv6 SID is entirely up
to the originator of the advertisement. While Section Sections 5 and
Section 6 list
the SRv6 Endpoint Behaviors that are normally expected to be used by
the specific route advertisements, the reception of other SRv6
Endpoint behaviors (e.g., new behaviors that may be introduced in the
future) is not considered an error. An unrecognized endpoint
behavior MUST NOT be considered invalid by the
receiver receiver, except for
behaviors that involve the use of arguments (refer to Section 3.2.1
for details on argument validation). An implementation MAY log a
rate-limited warning when it receives an unexpected behavior.
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 Length |Sub-Sub TLV //
| Sub-Sub-TLV | | Value //
| Type | | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SRv6 Service Data Sub-Sub-TLVs
o
SRv6 Service Data Sub-Sub-TLV Type (1 octet): Identifies
This field identifies the type of Sub-Sub-TLV. It is assigned
values from the IANA Registry IANA's "SRv6 Service Data Sub-Sub-TLVs".
o Sub-Sub-TLV Types"
subregistry.
SRv6 Service Data Sub-Sub-TLV Length (2 octets): Specifies
This field specifies the total length, in octets, of the Sub-Sub-TLV Sub-Sub-
TLV Value field.
o
SRv6 Service Data Sub-Sub-TLV Value (variable): Contains
This field contains data specific to the Sub-Sub-TLV Type.
3.2.1. SRv6 SID Structure Sub-Sub-TLV
SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for the SRv6 SID
structure
Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV is used to
advertise the lengths of the individual parts of the SRv6 SID SID, as
defined in [RFC8986]. The terms Locator Block and Locator Node
correspond to the B and N parts respectively parts, respectively, of the SRv6 Locator
that
are is defined in section Section 3.1 of [RFC8986]. It is carried as Sub-Sub-
TLV Sub-
Sub-TLV in the SRv6 SID Information Sub-TLV 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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Node | Function | Argument | Transposition |
| Length | Length | Length | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transposition |
| Offset |
+-+-+-+-+-+-+-+-+
Figure 5: SRv6 SID Structure Sub-Sub-TLV
o
SRv6 Service Data Sub-Sub-TLV Type (1 octet):
This field is set to 1 to represent the SRv6 SID Structure Sub-Sub-TLV.
o Sub-
Sub-TLV.
SRv6 Service Data Sub-Sub-TLV Length (2 octets):
This field contains a total length of 6 octets.
o
Locator Block Length (1 octet): Contains
This field contains the length of the SRv6 SID Locator Block in
bits.
o
Locator Node Length (1 octet): Contains
This field contains the length of the SRv6 SID Locator Node in
bits.
o
Function Length (1 octet): Contains
This field contains the length of the SRv6 SID Function in bits.
o
Argument Length (1 octet): Contains
This field contains the length of the SRv6 SID Argument in bits.
o
Transposition Length (1 octet): Size
This field is the size in bits for the part of the SID that has
been transposed (or shifted) into a an MPLS label field
o field.
Transposition Offset (1 octet): The
This field is the offset position in bits for the part of the SID
that has been transposed (or shifted) into a an MPLS label field.
Section 4 describes mechanisms for the signaling of the SRv6 Service
SID by transposing a variable part of the SRv6 SID value and carrying
them in existing MPLS label fields to achieve more efficient packing
of those service prefix NLRIs in BGP update messages. The SRv6 SID
Structure Sub-Sub-TLV 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 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 the MPLS label field.
The bits that have been shifted out MUST be set to 0 in the SID
value.
A 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.
The size of the MPLS label field limits the bits transposed from the
SRv6 SID value into it. E.g., For example, the size of the MPLS label
field in
[RFC4364] [RFC8277] is 20 bits while in [RFC7432] is [RFC4364] and [RFC8277] and 24 bits. bits in [RFC7432].
As defined in [RFC8986], the sum of the Locator Block Length (LBL),
Locator Node Length (LNL), Function Length (FL), and Argument Length
(AL) fields MUST be less than or equal to 128 and greater than the
sum of Transposition Offset and Transposition Length.
As an example, consider that the sum of the Locator Block and the
Locator Node parts is 64. For an SRv6 SID where the entire Function
part of size 16 bits is transposed, then the transposition offset is set
to 64 and the transposition length is set to 16. While for an SRv6 SID
SID, where the Function length FL is 24 bits and only the lower order 20 bits are
transposed (e.g. (e.g., due to the limit of the MPLS label field size), then the
transposition offset is set to 68 and the transposition length is set
to 20.
BGP speakers that do not support this specification may misinterpret,
on the reception of an SRv6-based BGP service route update, the part
of the SRv6 SID encoded in an MPLS label field(s) as MPLS label
values for MPLS-based services. Implementations supporting this
specification MUST provide a mechanism to control the advertisement
of SRv6-based BGP service routes on a per-neighbor and per-service
basis. The details of deployment designs and implementation options
are outside the scope of this document.
Arguments may be generally applicable for SIDs of only specific SRv6
Endpoint behaviors (e.g., End.DT2M) and therefore End.DT2M); therefore, the Argument length AL MUST be set to
0 for SIDs where the Argument is not applicable. A receiver is
unable to validate the applicability of arguments for SRv6 Endpoint
behaviors that are unknown to it and hence MUST ignore SRv6 SIDs with
arguments (indicated by a non-zero argument length) AL) with unknown endpoint
behaviors. For SIDs corresponding to an endpoint behavior that is
known, a receiver MUST validate that the consistency of the argument length AL with
the specific endpoint behavior definition.
4. Encoding SRv6 SID Information
The SRv6 Service SID(s) for a BGP Service Prefix are service prefix is carried in the
SRv6 Services TLVs of the BGP Prefix-SID Attribute. attribute.
For certain types of BGP Services 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 NLRIs, thus providing efficient packing.
However, for certain other types of BGP Services Services, like EVPN VPWS Virtual
Private Wire Service (VPWS) where a per-PW SID allocation is required
(i.e., End.DX2 behavior), each NLRI would have its own unique SID SID,
thereby resulting in inefficient packing.
To achieve efficient packing, this document allows the encoding of
the SRv6 Service SID either as a whole in either the SRv6 Services TLVs or
the encoding of only the common part of the SRv6 SID (e.g., Locator)
in the SRv6 Services TLVs and encoding the variable (e.g., Function
or Argument parts) in the existing label fields specific to that
service encoding. This later form of encoding is referred to as the
Transposition Scheme Scheme, where the SRv6 SID Structure Sub-Sub-TLV
describes the sizes of the parts of the SRv6 SID and also indicates
the offset of the variable part along with its length in the SRv6 SID
value. The use of the Transposition Scheme is RECOMMENDED for the
specific service encodings that allow it it, as described further in
Section
Sections 5 and Section 6.
As an example, for the EVPN VPWS service prefix described further in
Section 6.1.2, the Function part of the SRv6 SID is encoded in the
MPLS Label field of the NLRI NLRI, and the SID value in the SRv6 Services
TLV carries only the Locator part with the SRv6 SID Structure Sub-
Sub-TLV. 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
the bit position position, and Transposition Length indicates the number of
bits that are being taken out of the SID and put into the label
field.
In yet another example, for the EVPN Ethernet A-D Auto-Discovery (A-D)
per Ethernet Segment (ES) route described further in Section 6.1.1,
only the Argument of the SID needs to be signaled. This Argument
part of the SRv6 SID MAY be transposed in the Ethernet Segment
Identifier (ESI) Label field of the ESI Label Extended Community extended community, and
the SID value in the SRv6 Services TLV is set to 0 along with the
inclusion of the SRv6 SID Structure Sub-Sub-TLV. The SRv6 SID
Structure Sub-Sub-TLV defines the lengths of Locator Block, Locator
Node, Function Function, and Argument parts. The offset and length of the
Argument part SID value moved to the label field is set in
transposition offset and length of the SID
structure Structure TLV. The
receiving router is then able to put together the entire SRv6 Service
SID (e.g., for the End.DT2M behavior) behavior), placing the label value
received in the ESI Label field of the Ethernet A-D per ES route into
the correct transposition offset and length in the SRv6 SID with the
End.DT2M behavior received for an EVPN Route Type 3 value.
5. BGP based BGP-Based L3 Service over 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 SRv6 based that support SRv6-based L3 services advertises advertise overlay
service prefixes along with a Service SID enclosed in an SRv6 L3
Service TLV within the BGP Prefix-SID Attribute. attribute. This TLV serves two
purposes - -- first, it indicates that the egress PE supports SRv6
overlay
overlay, and the BGP ingress PE receiving this route MUST perform
IPv6 encapsulation and insert an SRH [RFC8754] when required; second,
it indicates the value of the Service SID to be used in the
encapsulation.
The
Thus, the Service SID thus signaled only has local significance at the
egress PE, where it may be allocated or configured on a per-CE per-Customer-
Edge (CE) or per-VRF basis. In practice, the SID may encode a cross-connect cross-
connect to a specific Address Family address family table (End.DT) or next-hop/interface (End.DX) next hop /
interface (End.DX), as defined in [RFC8986].
The SRv6 Service SID SHOULD be routable (refer section to Section 3.3 of
[RFC8986]) within the AS Autonomous System (AS) of the egress PE and
serves the dual purpose of providing reachability between ingress PE
and egress PE while also encoding the SRv6 Endpoint behavior.
When steering for SRv6 services is based on shortest path forwarding
(e.g., best-effort best effort or IGP Flexible Algorithm
[I-D.ietf-lsr-flex-algo]) [LSR-FLEX-ALGO]) to the
egress PE, the ingress PE encapsulates the IPv4 or IPv6 customer
packet in an outer IPv6 header (using H.Encaps or H.Encaps.Red
flavors specified in [RFC8986]) [RFC8986]), where the destination address is the
SRv6 Service SID associated with the related BGP route update.
Therefore, the ingress PE MUST perform a resolvability check for the
SRv6 Service SID before considering the received prefix for the BGP
best path computation. The resolvability is evaluated evaluated, as per
[RFC4271]. If the SRv6 SID is reachable via more than one forwarding
table, local policy is used to determine which table to use. The
result of an SRv6 Service SID resolvability (e.g., when provided via
IGP Flexible Algorithm) can be ignored if the ingress PE has a local
policy that allows an alternate steering mechanism to reach the
egress PE. The details of such steering mechanisms are outside the
scope of this document.
For service over SRv6 core, the egress PE sets the next-hop next hop to one of
its IPv6 addresses. Such an address MAY be covered by the SRv6
Locator from which the SRv6 Service SID is allocated. The next-hop next hop
is used for tracking the reachability of the egress PE based on
existing BGP procedures.
When the BGP route is received at an ingress PE is colored with a
Color Extended community Community and a valid SRv6 Policy is available, the
steering for service flows is performed performed, as described in Section 8 of
[I-D.ietf-spring-segment-routing-policy].
[IGMP-MLD-EVPN]. When the ingress PE determines (with the help of
the SRv6 SID Structure) that the Service SID belongs to the same SRv6
Locator as the last SRv6 SID (of the egress PE) in the SR Policy
segment list, it MAY exclude that last SRv6 SID when steering the
service flow. For example, the effective segment list of the SRv6
Policy associated with SID list <S1, S2, S3> would be <S1, S2, S3-Service-SID>. S3-
Service-SID>.
5.1. IPv4 VPN Over over SRv6 Core
The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
Over
over IPv6 Core core defined in [RFC8950].
Label
The label field of IPv4-VPN NLRI is encoded as specified in [RFC8277]
with the 20-bit Label Value set to the whole or a portion of the
Function part of the SRv6 SID when the Transposition Scheme of
encoding (Section 4) is used and otherwise used; otherwise, it is set to Implicit NULL.
When using the Transposition Scheme, the Transposition Length MUST be
less than or equal to 20 and less than or equal to the Function
Length. FL.
The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.
The SRv6 Endpoint behavior SHOULD be one of these: End.DX4, End.DT4,
or End.DT46.
5.2. IPv6 VPN Over over SRv6 Core
The MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN
over IPv6 Core is core, as defined in [RFC4659].
Label
The label field of the IPv6-VPN NLRI is encoded as specified in
[RFC8277] with the 20-bit Label Value set to the whole or a portion
of the Function part of the SRv6 SID when the Transposition Scheme of
encoding (Section 4) is used and otherwise used; otherwise, it is set to Implicit NULL.
When using the Transposition Scheme, the Transposition Length MUST be
less than or equal to 20 and less than or equal to the Function
Length. FL.
The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.
The SRv6 Endpoint behavior SHOULD be one of these: End.DX6, End.DT6,
or End.DT46.
5.3. Global IPv4 over SRv6 Core
The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 over
IPv6 Core is core, as defined in [RFC8950].
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The
SRv6 Endpoint behavior SHOULD be one of these: End.DX4, End.DT4, or
End.DT46.
5.4. Global IPv6 over SRv6 Core
The MP_REACH_NLRI over SRv6 core is encoded according to [RFC2545] [RFC2545].
The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.
The SRv6 Endpoint behavior SHOULD be one of these: End.DX6, End.DT6,
or End.DT46.
6. BGP based BGP-Based Ethernet VPN (EVPN) over SRv6
[RFC7432] provides an extendable method of building an Ethernet VPN
(EVPN) EVPN overlay.
It primarily focuses on MPLS based EVPNs MPLS-based EVPNs, and [RFC8365] extends to
IP-based EVPN overlays. [RFC7432] defines Route Types 1, 2, and 3 3,
which carry prefixes and MPLS Label fields; the Label fields have a
specific use for MPLS encapsulation of EVPN traffic. Route Type 5
carrying MPLS label information (and thus encapsulation information)
for an EVPN is defined in [RFC9136]. Route Types 6, 7, and 8 are
defined in [I-D.ietf-bess-evpn-igmp-mld-proxy].
o [RFC9251].
* Ethernet Auto-discovery Route Auto-Discovery (A-D) route (Route Type 1)
o
* MAC/IP Advertisement Route route (Route Type 2)
o
* Inclusive Multicast Ethernet Tag Route route (Route Type 3)
o
* Ethernet Segment route (Route Type 4)
o
* IP prefix Prefix route (Route Type 5)
o
* Selective Multicast Ethernet Tag route (Route Type 6)
o
* Multicast Membership Report Synch route (Route Type 7)
o
* Multicast Leave Synch route (Route Type 8)
The specifications for other EVPN Route Types are outside the scope
of this document.
To support SRv6 based SRv6-based EVPN overlays, one or more SRv6 Service SIDs
are advertised with Route Type Types 1, 2, 3, and 5. The SRv6 Service
SID(s) per Route Type are is advertised in SRv6 L3/L2 Service TLVs within
the BGP Prefix-SID Attribute. attribute. Signaling of the SRv6 Service SID(s)
serves two purposes - -- first, it indicates that the BGP egress device
supports SRv6 overlay overlay, and the BGP ingress device receiving this
route MUST perform IPv6 encapsulation and insert an SRH [RFC8754]
when required; second, it indicates the value of the Service SID(s)
to be used in the encapsulation.
The SRv6 Service SID SHOULD be routable (refer section to Section 3.3 of
[RFC8986]) within the AS of the egress PE and serves the dual purpose
of providing reachability between the ingress PE and egress PE while
also encoding the SRv6 Endpoint behavior.
When steering for SRv6 services is based on shortest path forwarding
(e.g., best-effort best effort or IGP Flexible Algorithm
[I-D.ietf-lsr-flex-algo]) [LSR-FLEX-ALGO]) to the
egress PE, the ingress PE encapsulates the customer Layer 2 Ethernet
packet in an outer IPv6 header (using H.Encaps.L2 or H.Encaps.L2.Red
flavors specified in [RFC8986]) where the destination address is the
SRv6 Service SID associated with the related BGP route update.
Therefore, the ingress PE MUST perform a resolvability check for the
SRv6 Service SID before considering the received prefix for the BGP
best path computation. The resolvability is evaluated as per
[RFC4271]. If the SRv6 SID is reachable via more than one forwarding
table, local policy is used to determine which table to use. The
result of an SRv6 Service SID resolvability (e.g., when provided via
IGP Flexible Algorithm) can be ignored if the ingress PE has a local
policy that allows an alternate steering mechanism to reach the
egress PE. The details of such steering mechanisms are outside the
scope of this document.
For service over SRv6 core, the egress PE sets the next-hop next hop to one of
its IPv6 addresses. Such an address MAY be covered by the SRv6
Locator from which the SRv6 Service SID is allocated. The next-hop next hop
is used for tracking the reachability of the egress PE based on
existing BGP procedures.
When the BGP route is received at an ingress PE is colored with a
Color Extended community Community and a valid SRv6 Policy is available, the
steering for service flows is performed as described in Section 8 of
[I-D.ietf-spring-segment-routing-policy].
[IGMP-MLD-EVPN]. When the ingress PE determines (with the help of
the SRv6 SID Structure) that the Service SID belongs to the same SRv6
Locator as the last SRv6 SID (of the egress PE) in the SR Policy
segment list, it MAY exclude that last SRv6 SID when steering the
service flow. For example, the effective segment list of the SRv6
Policy associated with SID list <S1, S2, S3> would be <S1, S2, S3-Service-SID>. S3-
Service-SID>.
6.1. Ethernet Auto-discovery Auto-Discovery Route over SRv6 Core
Ethernet Auto-Discovery (A-D) A-D routes are Route Type 1 1, as defined in
[RFC7432] [RFC7432], and
may be used to achieve split-horizon filtering, fast convergence, and
aliasing. EVPN Route Type 1 is also used in EVPN-
VPWS EVPN-VPWS as well as in EVPN flexible cross-connect;
EVPN-flexible cross-connect, mainly used to advertise point-to-point
services ID.
As a reminder, EVPN Route Type 1 is encoded as follows:
+---------------------------------------+
+-----------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet
+-----------------------------------------+
| Ethernet Segment Identifier (10 octets)|
+---------------------------------------+
+-----------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
+-----------------------------------------+
| MPLS label (3 octets) |
+---------------------------------------+
+-----------------------------------------+
Figure 6: EVPN Route Type 1
6.1.1. Ethernet A-D per ES Route
Ethernet A-D per ES route NLRI encoding over SRv6 core is as per
[RFC7432].
The 24-bit ESI label Label field of the ESI label Label extended community
carries the whole or a portion of the Argument part of the SRv6 SID
when the ESI filtering approach is used along with the Transposition
Scheme of encoding (Section 4) and otherwise 4); otherwise, it is set to the Implicit
NULL value. In either case, the value is set in the high order 20
bits (e.g., as 0x000030 in the case of Implicit NULL). When using
the Transposition Scheme, the Transposition Length MUST be less than
or equal to 24 and less than or equal to the Argument Length. AL.
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the A-D route. The
SRv6 Endpoint behavior SHOULD be End.DT2M. When the ESI filtering
approach is used, the Service SID is used to signal the Arg.FE2 SID
Argument for applicable End.DT2M behavior [RFC8986]. When the local-
bias approach [RFC8365] is used, the Service SID MAY be of value 0.
6.1.2. Ethernet A-D per EVI Route
Ethernet A-D per EVI EVPN Instance (EVI) route NLRI encoding over SRv6
core is similar to what is described in [RFC7432] and [RFC8214] with
the following change:
o
MPLS Label:
The 24-bit field carries the whole or a portion of the Function
part of the SRv6 SID when the Transposition Scheme of encoding
(Section 4) is used and otherwise used; otherwise, it is set to the Implicit NULL
value. In either case, the value is set in the high order 20 bits
(e.g., as 0x000030 in the case of Implicit NULL). When using the
Transposition Scheme, the Transposition Length MUST be less than
or equal to 24 and less than or equal to the Function Length. FL.
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the A-D route. The
SRv6 Endpoint behavior SHOULD be one of these: End.DX2, End.DX2V, or
End.DT2U.
6.2. MAC/IP Advertisement Route over SRv6 Core
EVPN Route Type 2 is used to advertise unicast traffic MAC+IP Media Access
Control (MAC) + IP address reachability through MP-BGP to all other
PEs in a given EVPN instance.
As a reminder, EVPN Route Type 2 is encoded as follows:
+---------------------------------------+
+-----------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet
+-----------------------------------------+
| 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 (3 octets) |
+---------------------------------------+
+-----------------------------------------+
| MPLS Label2 (0 or 3 octets) |
+---------------------------------------+
+-----------------------------------------+
Figure 7: EVPN Route Type 2
NLRI encoding over SRv6 core is similar to what is described in
[RFC7432] with the following changes:
o
MPLS Label1: Is
This is associated with the SRv6 L2 Service TLV. This 24-bit
field carries the whole or a portion of the Function part of the
SRv6 SID when the Transposition Scheme of encoding (Section 4) is used and otherwise
used; otherwise, it is set to the Implicit NULL value. In either
case, the value is set in the high order 20 bits (e.g., as
0x000030 in the case of Implicit NULL). When using the
Transposition Scheme, the Transposition Length MUST be less than
or equal to 24 and less than or equal to the Function Length.
o FL.
MPLS Label2: Is
This is associated with the SRv6 L3 Service TLV. This 24-bit
field carries the whole or a portion of the Function part of the
SRv6 SID when the Transposition Scheme of encoding (Section 4) is used and otherwise
used; otherwise, it is set to the Implicit NULL value. In either
case, the value is set in the high order 20 bits (e.g., as
0x000030 in the case of Implicit NULL). When using the
Transposition Scheme, the Transposition Length MUST be less than
or equal to 24 and less than or equal to the Function Length. FL.
Service SIDs enclosed in the SRv6 L2 Service TLV and optionally in
the SRv6 L3 Service TLV within the BGP Prefix-SID attribute is are
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
This is associated with the SRv6 L2 Service TLV. This 24-bit
field carries the whole or a portion of the Function part of the
SRv6 SID when the Transposition Scheme of encoding (Section 4) is used and otherwise
used; otherwise, it is set to the Implicit NULL value. In either
case, the value is set in the high order 20 bits (e.g., as
0x000030 in the case of Implicit NULL). When using the
Transposition Scheme, the Transposition Length MUST be less than
or equal to 24 and less than or equal to the Function Length. FL.
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the route. The SRv6
Endpoint behavior SHOULD be one of these: End.DX2, End.DX2 or End.DT2U.
6.2.2. MAC/IP Advertisement Route with MAC+IP
o
MPLS Label1: Is
This is associated with the SRv6 L2 Service TLV. This 24-bit
field carries the whole or a portion of the Function part of the
SRv6 SID when the Transposition Scheme of encoding (Section 4) is used and otherwise
used; otherwise, it is set to the Implicit NULL value. In either
case, the value is set in the high order 20 bits (e.g., as
0x000030 in the case of Implicit NULL). When using the
Transposition Scheme, the Transposition Length MUST be less than
or equal to 24 and less than or equal to the Function Length.
o FL.
MPLS Label2: Is
This is associated with the SRv6 L3 Service TLV. This 24-bit
field carries the whole or a portion of the Function part of the
SRv6 SID when the Transposition Scheme of encoding (Section 4) is used and otherwise
used; otherwise, it is set to the Implicit NULL value. In either
case, the value is set in the high order 20 bits (e.g., as
0x000030 in the case of Implicit NULL). When using the
Transposition Scheme, the Transposition Length MUST be less than
or equal to 24 and less than or equal to the Function Length. FL.
An L2 Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the route. In
addition, an L3 Service SID enclosed in an SRv6 L3 Service TLV within
the BGP Prefix-SID attribute MAY also be advertised along with the
route. The SRv6 Endpoint behavior SHOULD be one of these: for the L2
Service SID - End.DX2, End.DT2U; SID, End.DX2 or End.DT2U and for the L3 Service SID - SID,
End.DT46, End.DT4, End.DT6, End.DX4, or End.DX6.
6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core
EVPN Route Type 3 is used to advertise multicast traffic reachability
information through MP-BGP to all other PEs in a given EVPN instance.
As a reminder, EVPN Route Type 3 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) |
+---------------------------------------+
Figure 8: EVPN Route Type 3
NLRI encoding over SRv6 core is similar to what is described in
[RFC7432].
PMSI
The P-Multicast Service Interface (PMSI) Tunnel Attribute [RFC6514]
is used to identify the P-tunnel Provider tunnel (P-tunnel) used for sending broadcast, unknown unicast,
Broadcast, Unknown Unicast, or multicast Multicast (BUM) traffic. The format
of the PMSI Tunnel Attribute is encoded as follows over SRv6
Core: core:
+---------------------------------------+
| Flag (1 octet) |
+---------------------------------------+
| Tunnel Type (1 octet) |
+---------------------------------------+
| MPLS label (3 octet) octets) |
+---------------------------------------+
| Tunnel Identifier (variable) |
+---------------------------------------+
Figure 9: PMSI Tunnel Attribute
o
Flag: zero
This field has a value of 0, as defined per [RFC7432]
o [RFC7432].
Tunnel Type:
This field is defined per [RFC6514]
o [RFC6514].
MPLS label:
This 24-bit field carries the whole or a portion of the Function
part of the SRv6 SID when ingress replication is used and the
Transposition Scheme of encoding (Section 4) is used and used; otherwise,
it is set as defined in [RFC6514]. When using the Transposition
Scheme, the Transposition Length MUST be less than or equal to 24
and less than or equal to the Function Length.
o FL.
Tunnel Identifier:
This field is the IP address of egress PE PE.
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the route. The SRv6
Endpoint behavior SHOULD be End.DT2M.
o
* When ESI-based filtering is used for Multi-Homing multihoming or E-Tree Ethernet Tree
(E-Tree) procedures, the ESI Filtering Argument (the Arg.FE2
notation introduced in [RFC8986]) of the Service SID carried along
with EVPN Route Type 1 route SHOULD be merged with the applicable
End.DT2M SID of Route Type 3 route advertised by the remote PE by doing
a
bit-wise bitwise logical-OR operation to create a single SID on the
ingress PE. Details of split-horizon split-horizon, ESI-based filtering
mechanisms for multihoming are described in [RFC7432]. Details of
filtering mechanisms for Leaf-originated BUM traffic in EVPN
E-Tree services are provided in [RFC8317].
o
* When "local-bias" is used as the Multi-Homing multihoming split-horizon method,
the ESI Filtering Argument SHOULD NOT be merged with the
corresponding End.DT2M SID on the ingress PE. Details of the
"local-bias"
local-bias procedures are described in [RFC8365].
Usage of multicast trees as P-tunnels is outside the scope of this
document.
6.4. Ethernet Segment Route over SRv6 Core
As a reminder, an Ethernet Segment route (i.e., EVPN 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) |
+---------------------------------------+
Figure 10: EVPN Route Type 4
NLRI encoding over SRv6 core is similar to what is described in
[RFC7432].
SRv6 Service TLVs within the 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 Core
EVPN Route Type 5 is used to advertise IP address reachability
through MP-BGP to all other PEs in a given EVPN instance. The IP
address may include a host IP prefix or any specific subnet.
As a reminder, EVPN Route Type 5 is encoded as follows:
+---------------------------------------+
+-----------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet
+-----------------------------------------+
| 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 (3 octets) |
+---------------------------------------+
+-----------------------------------------+
Figure 11: EVPN Route Type 5
NLRI encoding over SRv6 core is similar to what is described in
[RFC9136] with the following change:
o
MPLS Label:
This 24-bit field carries the whole or a portion of the Function
part of the SRv6 SID when the Transposition Scheme of encoding
(Section 4) is used and otherwise used; otherwise, it is set to the Implicit NULL
value. In either case, the value is set in the high order 20 bits
(e.g., as 0x000030 in the case of Implicit NULL). When using the
Transposition Scheme, the Transposition Length MUST be less than
or equal to 24 and less than or equal to the Function Length. FL.
The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.
The SRv6 Endpoint behavior SHOULD be one of these: End.DT4, End.DT6,
End.DT46, End.DX4, or End.DX6.
6.6. EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6 Core
These routes do not require the advertisement of SRv6 Service TLVs
along with them. Similar to EVPN Route Type 4, the BGP Nexthop next hop is
equal to the IPv6 address of egress PE.
7. Implementation Status
[Note to RFC Editor: This section needs to be removed before
publication as RFC.]
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.
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 the SRv6 L3 Service TLV are encountered, all
but the first instance MUST be ignored.
If multiple instances of the SRv6 L2 Service TLV are encountered, all
but the first instance MUST be ignored.
An SRv6 Service TLV is considered malformed in the following cases:
o the
* The TLV Length is less than 1
o the 1.
* The TLV Length is inconsistent with the length of the BGP Prefix-SID
attribute
o at Prefix-
SID attribute.
* At least one of the constituent Sub-TLVs is malformed malformed.
An SRv6 Service Sub-TLV is considered malformed in the following
cases:
o the
case:
* The Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 Service TLV TLV.
An SRv6 SID Information Sub-TLV is considered malformed in the
following cases:
* the The Sub-TLV Length is less than 21 21.
* the The Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 Service TLV TLV.
* at At least one of the constituent Sub-Sub-TLVs is malformed malformed.
An SRv6 Service Data Sub-Sub-TLV is considered malformed in the
following cases:
o the case:
* The Sub-Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 service Sub-TLV Sub-TLV.
Any TLV or Sub-TLV TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because
its Type is unrecognized.
Any TLV or Sub-TLV TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because
of failing any semantic validation of its Value field.
The SRv6 overlay service requires the Service SID for forwarding.
The treat-
as-withdraw treat-as-withdraw action [RFC7606] MUST be performed when at
least one malformed SRV6 SRv6 Service TLV is present in the BGP Prefix-SID
attribute.
The SRv6 SID value in the SRv6 SID Information Sub-TLV is invalid
when the SID Structure Sub-Sub-TLV transposition length is greater
than the number of bits of the label field or if any of the
conditions for the fields of the sub-sub-TLV Sub-Sub-TLV, as specified in
Section 3.2.1 3.2.1, is not met. The transposition offset and length MUST
be 0 when the Sub-Sub-TLV is advertised along with routes where the
transposition scheme is not applicable (e.g., for Global global IPv6 Service service
[RFC2545] where there is no label field). The path having any such
Prefix-SID Attribute attribute without any valid SRv6 SID information MUST be
considered ineligible during the selection of the best path for the
corresponding prefix.
9.
8. IANA Considerations
9.1.
8.1. BGP Prefix-SID TLV Types Registry
This document introduces two new TLV Types of the BGP Prefix-SID
attribute. IANA has assigned Type values in the registry "BGP Prefix-SID TLV
Types" subregistry as follows:
+=======+=====================+===========+
| Value | Type | Reference
-------------------------------------------- |
+=======+=====================+===========+
| 4 | Deprecated <this document> | RFC 9252 |
+-------+---------------------+-----------+
| 5 | SRv6 L3 Service TLV <this document> | RFC 9252 |
+-------+---------------------+-----------+
| 6 | SRv6 L2 Service TLV <this document>
Figure 12: | RFC 9252 |
+-------+---------------------+-----------+
Table 1: BGP Prefix-SID TLV Types
The value
Subregistry
Value 4 previously corresponded to the SRv6-VPN SID TLV, which was
specified in previous earlier draft versions of this 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.
8.2. SRv6 Service Sub-TLV Types Registry
IANA is requested to create has created and maintain now maintains a new registry subregistry called "SRv6
Service Sub-TLV Types" under the "Border Gateway Protocol (BGP)
Parameters" registry. The allocation policy registration procedures, per [RFC8126],
for this registry is:
0 : Reserved subregistry are according to Table 2.
+=========+=========================+
| Range | Registration Procedure |
+=========+=========================+
| 1-127 : | IETF Review |
+---------+-------------------------+
| 128-254 : | First Come First Served |
+---------+-------------------------+
| 255 : Reserved
Figure 13: | IETF Review |
+---------+-------------------------+
Table 2: SRv6 Service Sub-TLV
Types Allocation Policy
The following Subregistry Registration
Procedures
IANA has populated this subregistry as follows. Note that the SRv6
SID Information Sub-TLV Type is defined in this document:
+=======+==============================+===========+
| Value | Type | Reference
---------------------------------------------------- |
+=======+==============================+===========+
| 0 | Reserved | RFC 9252 |
+-------+------------------------------+-----------+
| 1 | SRv6 SID Information Sub-TLV <this document>
Figure 14: | RFC 9252 |
+-------+------------------------------+-----------+
| 255 | Reserved | RFC 9252 |
+-------+------------------------------+-----------+
Table 3: SRv6 Service Sub-TLV Types
9.3. Subregistry
Initial Contents
8.3. SRv6 Service Data Sub-Sub-TLV Types Registry
IANA is requested to create has created and maintain now maintains a new registry subregistry called "SRv6
Service Data Sub-Sub-TLV Types" under the "Border Gateway Protocol
(BGP) Parameters" registry. The allocation policy registration procedures for this registry
is:
0 : Reserved
subregistry are according to Table 4.
+=========+=========================+
| Range | Registration Procedure |
+=========+=========================+
| 1-127 : | IETF Review |
+---------+-------------------------+
| 128-254 : | First Come First Served |
+---------+-------------------------+
| 255 : Reserved
Figure 15: | IETF Review |
+---------+-------------------------+
Table 4: SRv6 Service Data Sub-Sub-TLV Sub-
Sub-TLV Types Allocation Policy Subregistry
Registration Procedures
The following Sub-Sub-TLV Type is defined in this document:
+=======+================================+===========+
| Value | Type | Reference
---------------------------------------------------- |
+=======+================================+===========+
| 0 | Reserved | RFC 9252 |
+-------+--------------------------------+-----------+
| 1 | SRv6 SID Structure Sub-Sub-TLV <this document>
Figure 16: | RFC 9252 |
+-------+--------------------------------+-----------+
| 255 | Reserved | RFC 9252 |
+-------+--------------------------------+-----------+
Table 5: SRv6 Service Data Sub-Sub-TLV Types
9.4.
Subregistry Initial Contents
8.4. BGP SRv6 Service SID Flags Registry
IANA is requested to create has created and maintain now maintains a new registry subregistry called "BGP SRv6
Service SID Flags" under the "Border Gateway Protocol (BGP)
Parameters" registry. The allocation policy registration procedure for this registry
subregistry is IETF Review Review, and all 8 bit 8-bit positions of the flags are
currently unassigned.
9.5. Subsequent Address Family Identifiers (SAFI) Parameters
8.5. SAFI Values Registry
IANA is requested to add has added this document as a reference for value 128 ("MPLS-
labeled VPN address") in the "SAFI Values" subregistry under the
"Subsequent Address Family Identifiers (SAFI) Parameters" registry.
10.
9. Security Considerations
This document specifies extensions to the BGP protocol for the
signaling of services for SRv6. These specifications leverage
existing BGP protocol mechanisms for the signaling of various types
of services. It also builds upon existing elements of the SR
architecture (more
specifically specifically, SRv6). As such, this section
largely provides pointers (as a reminder) to the security
considerations of those existing specifications while also covering certain
certain, newer security aspects for the specifications newly
introduced by this document.
10.1. BGP Session Related
9.1. Considerations Related to BGP Sessions
Techniques related to authentication of BGP sessions for securing
messages between BGP peers peers, as discussed in the BGP specification
[RFC4271] and, and in the security analysis for BGP [RFC4272] [RFC4272], apply. The
discussion of the use of the TCP Authentication option Option to protect BGP
sessions is found in [RFC5925], while [RFC6952] includes an analysis
of BGP keying and authentication issues. This document does not
introduce any additional BGP session security considerations.
10.2.
9.2. Considerations Related to BGP Services Related Considerations
This document does not introduce new services or BGP NLRI types but
extends the signaling of existing ones for SRv6. Therefore, the
security considerations for the respective BGP services services, such as BGP
IPv4 over IPv6 NH [RFC8950], BGP IPv6 L3VPN [RFC4659], BGP IPv6
[RFC2545], BGP EVPN [RFC7432] [RFC7432], and IP EVPN [RFC9136] [RFC9136], apply as
discussed in their respective documents. [RFC8669] discusses
mechanisms to prevent the leaking of the BGP Prefix-SID attribute, that
which carries SR information, outside the SR domain.
As a reminder, several of the BGP services (i.e., the AFI/SAFI used
for their signaling) were initially introduced for one encapsulation
mechanism and later extended for others others, e.g., EVPN MPLS [RFC7432]
was extended for VXLAN/NVGRE Virtual eXtensible Local Area Network (VXLAN)
encapsulation and Network Virtualization Using Generic Routing
Encapsulation (NVGRE) [RFC8365]. [RFC9012] enables the use of
various IP encapsulation mechanisms along with different BGP SAFIs
for their respective services. The existing filtering mechanisms for
preventing the leak of the encapsulation information (carried in BGP
attributes) and to prevent preventing the advertisement of prefixes from the
provider's internal address space (especially the SRv6 Block Block, as
discussed in [RFC8986]) to external peers (or into the Internet) also
apply in the case of SRv6.
Specific to SRv6, a misconfig misconfiguration or error in the above mentioned BGP filtering
mechanisms mentioned above may result in exposing information information, such
as SRv6 Service SIDs to external peers or other unauthorized
entities. However, an attempt to exploit this information or to
raise an attack by injecting packets into the network (e.g. (e.g., customer
networks in case of VPN services) is mitigated by the existing SRv6
data plane security mechanisms mechanisms, as described in the next section.
10.3.
9.3. Considerations Related to SR over IPv6 Data Plane Related Considerations
This section provides a brief reminder and an overview of the
security considerations related to SRv6 with pointers to existing
specifications. This document introduces no new security
considerations of its own from the SRv6 data plane perspective.
SRv6 operates within a trusted SR domain. The data packets
corresponding to service flows between PE routers are encapsulated
(using SRv6 SIDs advertised via BGP) and carried within this trusted
SR domain (e.g., within a single AS or between multiple ASes within a
single provider network).
The security considerations of the Segment Routing SR architecture are covered by
[RFC8402]. More detailed security considerations considerations, specifically of
SRv6 and SRH SRH, are covered by [RFC8754] as they relate to SR Attacks (section
(Section 7.1), Service Theft (section 7.2) (Section 7.2), and Topology Disclosure (section
(Section 7.3). As such such, an operator deploying SRv6 MUST follow the
considerations described in [RFC8754] section Section 7 of [RFC8754] to implement the
infrastructure ACLs, Access Control Lists (ACLs) and the recommendations
described in BCP 38 [RFC2827] and BCP 84
[RFC3704] recommendations. [RFC3704].
The SRv6 deployment and SID allocation guidelines guidelines, as described in
[RFC8986]
[RFC8986], simplify the deployment of the ACL filters (e.g., a single
ACL corresponding to the SRv6 Block applied to the external
interfaces on border nodes is sufficient to block packets destined to
any SRv6 SID in the domain from external/unauthorized networks).
While there is an assumed trust model within a an SR domain domain, such that
any node sending a packet to an SRv6 SID is assumed to be allowed to
do so, there is also the option of using an SRH HMAC Hashed Message
Authentication Code (HMAC) TLV [RFC8754] [RFC8754], as described in [RFC8986] [RFC8986],
for validation.
The SRv6 SID Endpoint behaviors implementing the services signalled signaled in
this document are defined in [RFC8986] and hence [RFC8986]; hence, the security
considerations of that document apply. These considerations are
independent of the protocol used for service deployment, i.e. i.e.,
independent of BGP signaling of SRv6 services.
These considerations help protect transit traffic as well as
services, such as VPNs, to avoid service theft or injection of
traffic into customer VPN.
11.
13. VPNs.
10. References
13.1.
10.1. Normative References
[I-D.ietf-bess-evpn-igmp-mld-proxy]
Sajassi, A., Thoria, S., Mishra, M., Drake, J., and W.
Lin, "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-
igmp-mld-proxy-20 (work in progress), March 2022.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K.
Patel, "Advertising IPv4 Network Layer Reachability
Information (NLRI) with an IPv6 Next Hop", RFC 8950,
DOI 10.17487/RFC8950, November 2020,
<https://www.rfc-editor.org/info/rfc8950>.
[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>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>.
13.2.
[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
and W. Lin, "Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Proxies for Ethernet
VPN (EVPN)", RFC RFC9251, DOI 10.17487/RFC9251, June 2022,
<https://www.rfc-editor.org/info/rfc9251>.
10.2. Informative References
[I-D.ietf-idr-segment-routing-te-policy]
[IDR-SEGMENT-ROUTING-TE-POLICY]
Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., Jain, D., and S. Lin, "Advertising Segment Routing
Policies in BGP", draft-ietf-idr-segment-routing-te-
policy-16 (work Work in progress), March 2022.
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-18 (work in progress), October 2021.
[I-D.ietf-spring-segment-routing-policy] Progress, Internet-Draft, draft-
ietf-idr-segment-routing-te-policy-17, 14 April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
segment-routing-te-policy-17>.
[IGMP-MLD-EVPN]
Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-21 (work
Work in progress), Progress, Internet-Draft, draft-ietf-spring-
segment-routing-policy-22, 22 March 2022.
[I-D.matsushima-spring-srv6-deployment-status]
Matsushima, 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
segment-routing-policy-22>.
[LSR-FLEX-ALGO]
Psenak, P., Ed., Hegde, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman, Talaulikar, K.,
and A. Dhamija, "SRv6 Implementation and Deployment
Status", draft-matsushima-spring-srv6-deployment-status-13
(work Gulko, "IGP Flexible Algorithm", Work in progress), March 2022. Progress,
Internet-Draft, draft-ietf-lsr-flex-algo-20, 18 May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
flex-algo-20>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
Acknowledgments
Acknowledgements
The authors of this document would like to thank Stephane Litkowski,
Rishabh Parekh, Xiejingrong, Rajesh M, M., Mustapha Aissaoui, Alexander
Vainshtein, Eduard Metz, Shraddha Hegde, Eduard Vasilenko, Ron
Bonica, and Joel Halpern for their comments and review of this
document. The authors would also like to thank Document Shepherd
Matthew Bocci for his
document shepherd review and AD Martin Vigoureux for his AD review
that resulted in helpful comments for improving this document.
12.
Contributors
Clarence Filsfils
Cisco
Email: cfilsfil@cisco.com
Satoru Matsushima
SoftBank
Email: satoru.matsushima@g.softbank.co.jp
Dirk Steinberg
Steinberg Consulting
Email: dirk@lapishills.com
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
Authors' Addresses
Gaurav Dawra (editor)
LinkedIn
USA
United States of America
Email: gdawra.ietf@gmail.com
Ketan Talaulikar (editor)
Cisco Systems
India
Email: ketant.ietf@gmail.com
Robert Raszuk
NTT Network Innovations
940 Stewart Dr Dr.
Sunnyvale, CA 94085
USA
United States of America
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
United States of America
Email: jorge.rabadan@nokia.com