draft-ietf-bess-srv6-services-01.txt   draft-ietf-bess-srv6-services-02.txt 
BESS Working Group BESS Working Group G. Dawra, Ed.
Internet-Draft Internet-Draft LinkedIn
Intended status: Standards Track G. Dawra, Ed. Intended status: Standards Track C. Filsfils
Expires: May 6, 2020 LinkedIn Expires: August 30, 2020 Cisco Systems
C. Filsfils
Cisco Systems
R. Raszuk R. Raszuk
Bloomberg LP Bloomberg LP
B. Decraene B. Decraene
Orange Orange
S. Zhuang S. Zhuang
Huawei Technologies Huawei Technologies
J. Rabadan J. Rabadan
Nokia Nokia
November 3, 2019 February 27, 2020
SRv6 BGP based Overlay services SRv6 BGP based Overlay services
draft-ietf-bess-srv6-services-01 draft-ietf-bess-srv6-services-02
Abstract Abstract
This draft defines procedures and messages for SRv6-based BGP This draft defines procedures and messages for SRv6-based BGP
services including L3VPN, EVPN and Internet services. It builds on services including L3VPN, EVPN and Internet services. It builds on
RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432
"BGP MPLS-Based Ethernet VPN". "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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2020. This Internet-Draft will expire on August 30, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. SRv6 Services TLVs . . . . . . . . . . . . . . . . . . . . . 4 2. SRv6 Services TLVs . . . . . . . . . . . . . . . . . . . . . 4
2.1. SRv6 Service Sub-TLVs . . . . . . . . . . . . . . . . . . 5 3. SRv6 Service Sub-TLVs . . . . . . . . . . . . . . . . . . . . 5
2.1.1. SRv6 SID Information Sub-TLV . . . . . . . . . . . . 5 3.1. SRv6 SID Information Sub-TLV . . . . . . . . . . . . . . 6
2.1.2. SRv6 Service Data Sub-Sub-TLVs . . . . . . . . . . . 6 3.2. SRv6 Service Data Sub-Sub-TLVs . . . . . . . . . . . . . 7
3. BGP based L3 service over SRv6 . . . . . . . . . . . . . . . 9 3.2.1. SRv6 SID Structure Sub-Sub-TLV . . . . . . . . . . . 7
3.1. IPv4 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 9 4. Encoding SRv6 SID information . . . . . . . . . . . . . . . . 9
3.2. IPv6 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 10 5. BGP based L3 service over SRv6 . . . . . . . . . . . . . . . 10
3.3. Global IPv4 over SRv6 Core . . . . . . . . . . . . . . . 10 5.1. IPv4 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 11
3.4. Global IPv6 over SRv6 Core . . . . . . . . . . . . . . . 10 5.2. IPv6 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 11
4. BGP based Ethernet VPN (EVPN) over SRv6 . . . . . . . . . . . 11 5.3. Global IPv4 over SRv6 Core . . . . . . . . . . . . . . . 12
4.1. Ethernet Auto-discovery route over SRv6 Core . . . . . . 11 5.4. Global IPv6 over SRv6 Core . . . . . . . . . . . . . . . 12
4.1.1. Per-ES A-D route . . . . . . . . . . . . . . . . . . 12 6. BGP based Ethernet VPN (EVPN) over SRv6 . . . . . . . . . . . 12
4.1.2. Per-EVI A-D route . . . . . . . . . . . . . . . . . . 12 6.1. Ethernet Auto-discovery route over SRv6 Core . . . . . . 13
4.2. MAC/IP Advertisement route over SRv6 Core . . . . . . . . 13 6.1.1. Per-ES A-D route . . . . . . . . . . . . . . . . . . 13
4.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core . . 15 6.1.2. Per-EVI A-D route . . . . . . . . . . . . . . . . . . 14
4.4. Ethernet Segment route over SRv6 Core . . . . . . . . . . 16 6.2. MAC/IP Advertisement route over SRv6 Core . . . . . . . . 14
4.5. IP prefix route over SRv6 Core . . . . . . . . . . . . . 17 6.2.1. MAC/IP Advertisement route with MAC Only . . . . . . 15
4.6. EVPN multicast routes (Route Types 6, 7, 8) over SRv6 6.2.2. MAC/IP Advertisement route with MAC+IP . . . . . . . 16
core . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core . . 16
5. Encoding SRv6 SID information . . . . . . . . . . . . . . . . 18 6.4. Ethernet Segment route over SRv6 Core . . . . . . . . . . 18
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 6.5. IP prefix route over SRv6 Core . . . . . . . . . . . . . 18
7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 19 6.6. EVPN multicast routes (Route Types 6, 7, 8) over SRv6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 core . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. BGP Prefix-SID TLV Types registry . . . . . . . . . . . . 21 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
8.2. SRv6 Service Sub-TLV Types registry . . . . . . . . . . . 21 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 19
8.3. SRv6 Service Data Sub-Sub-TLV Types registry . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9.1. BGP Prefix-SID TLV Types registry . . . . . . . . . . . . 20
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.2. SRv6 Service Sub-TLV Types registry . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.3. SRv6 Service Data Sub-Sub-TLV Types registry . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
SRv6 refers to Segment Routing instantiated on the IPv6 dataplane [I- SRv6 refers to Segment Routing [RFC8402] instantiated on the IPv6
D.ietf-spring-srv6-network-programming][I-D.ietf-6man-segment-routing dataplane [I-D.ietf-6man-segment-routing-header].
-header].
SRv6 based BGP services refers to the L3 and L2 overlay services with SRv6 based BGP services refers to the L3 and L2 overlay services with
BGP as control plane and SRv6 as dataplane. BGP as control plane and SRv6 as dataplane.
SRv6 SID refers to a SRv6 Segment Identifier as defined in SRv6 SID refers to a SRv6 Segment Identifier as defined in [RFC8402].
[I-D.ietf-spring-srv6-network-programming].
SRv6 Service SID refers to an SRv6 SID associated with one of the SRv6 Service SID refers to an SRv6 SID associated with one of the
service specific behavior on the advertising Provider Edge(PE) service specific behavior on the advertising Provider Edge (PE)
router, such as (but not limited to), END.DT (Table lookup in a VRF) 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 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]. service as defined in [I-D.ietf-spring-srv6-network-programming].
To provide SRv6 service with best-effort connectivity, the egress PE To provide SRv6 service with best-effort connectivity, the egress PE
signals an SRv6 Service SID with the BGP overlay service route. The signals an SRv6 Service SID with the BGP overlay service route. The
ingress PE encapsulates the payload in an outer IPv6 header where the ingress PE encapsulates the payload in an outer IPv6 header where the
destination address is the SRv6 Service SID provided by the egress destination address is the SRv6 Service SID provided by the egress
PE. The underlay between the PEs only need to support plain IPv6 PE. The underlay between the PEs only need to support plain IPv6
forwarding [RFC8200]. forwarding [RFC8200].
To provide SRv6 service in conjunction with an underlay SLA from the 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 ingress PE to the egress PE, the egress PE colors the overlay service
route with a Color extended community route with a Color extended community
[I-D.ietf-idr-segment-routing-te-policy]. The ingress PE [I-D.ietf-idr-segment-routing-te-policy]. The ingress PE
encapsulates the payload packet in an outer IPv6 header with an SRH encapsulates the payload packet in an outer IPv6 header with the
that contains the segment list of SR policy associated with the segment list of SR policy associated with the related SLA followed by
related SLA followed by the SRv6 Service SID associated with the the SRv6 Service SID associated with the route. The underlay nodes
route. The underlay nodes whose SRv6 SID's are part of the SRH MUST whose SRv6 SID's are part of the segment list MUST support SRv6 data
support SRv6 data plane. plane.
BGP is used to advertise the reachability of prefixes of a particular BGP is used to advertise the reachability of prefixes of a particular
service from an egress PE to ingress PE nodes. service from an egress PE to ingress PE nodes.
This document describes how existing BGP messages between PEs may This document describes how existing BGP messages between PEs may
carry SRv6 Service SIDs as a means to interconnect PEs and form VPNs. 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 2. SRv6 Services TLVs
This document extends the BGP Prefix-SID attribute This document extends the BGP Prefix-SID attribute [RFC8669] to carry
[I-D.ietf-idr-bgp-prefix-sid] to carry SRv6 SIDs and associated SRv6 SIDs and associated information.
information.
The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix- 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 SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2
services. services.
o SRv6 L3 Service TLV: This TLV encodes Service SID information for o SRv6 L3 Service TLV: This TLV encodes Service SID information for
SRv6 based L3 services. It corresponds to the equivalent SRv6 based L3 services. It corresponds to the equivalent
functionality provided by an MPLS Label when received with a Layer functionality provided by an MPLS Label when received with a Layer
3 service route. Some behaviors which MAY be encoded, but not 3 service route. Some behaviors which MAY be encoded, but not
limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc. limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc.
o SRv6 L2 Service TLV: This TLV encodes Service SID information for o SRv6 L2 Service TLV: This TLV encodes Service SID information for
SRv6 based L2 services. It corresponds to the equivalent SRv6 based L2 services. It corresponds to the equivalent
functionality provided by an MPLS Label1 for EVPN Route-Types as functionality provided by an MPLS Label1 for EVPN Route-Types as
defined in[RFC7432]. Some behaviors which MAY be encoded, but not defined in[RFC7432]. Some behaviors which MAY be encoded, but not
limited to, are End.DX2, End.DX2V, End.DT2U, End.DT2M etc. 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, 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 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 TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs
defined in [RFC4760][RFC4659][RFC5549][RFC7432][RFC4364] where defined in [RFC4760] [RFC4659] [I-D.ietf-bess-rfc5549revision]
applicable as described in section 3 and 4. [RFC7432] [RFC4364] where applicable as described in Section 5 and
Section 6.
The following depicts the SRv6 Service TLVs encoded in the BGP The following depicts the SRv6 Service TLVs encoded in the BGP
Prefix-SID Attribute: Prefix-SID Attribute:
0 1 2 3 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 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 | | TLV Type | TLV Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Service Sub-TLVs // // SRv6 Service Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o TLV Type (1 octet): This field is assigned values from the IANA o TLV Type (1 octet): This field is assigned values from the IANA
registry "BGP Prefix-SID TLV Types". It is set to [TBD1] (to be registry "BGP Prefix-SID TLV Types". It is set to TBD1 (to be
assigned by IANA) for SRv6 L3 Service TLV. It is set to [TBD2] assigned by IANA) for SRv6 L3 Service TLV. It is set to TBD2 (to
(to be assigned by IANA) for SRv6 L2 Service TLV. be assigned by IANA) for SRv6 L2 Service TLV.
o TLV Length (2 octets): Specifies the total length of the TLV o TLV Length (2 octets): Specifies the total length of the TLV
Value. Value.
o RESERVED (1 octet): This field is reserved; it SHOULD be set to 0 o RESERVED (1 octet): This field is reserved; it SHOULD be set to 0
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
o SRv6 Service Sub-TLVs (variable): This field contains SRv6 Service o SRv6 Service Sub-TLVs (variable): This field contains SRv6 Service
related information and is encoded as an unordered list of Sub- related information and is encoded as an unordered list of Sub-
TLVs whose format is described below. TLVs whose format is described below.
2.1. SRv6 Service Sub-TLVs 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: The format of a single SRv6 Service Sub-TLV is depicted below:
0 1 2 3 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 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 // | SRv6 Service | SRv6 Service | SRv6 Service //
| Sub-TLV | Sub-TLV | Sub-TL // | Sub-TLV | Sub-TLV | Sub-TLV //
| Type | Length | value // | Type | Length | value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o SRv6 Service Sub-TLV Type (1 octet): Identifies the type of SRv6 o SRv6 Service Sub-TLV Type (1 octet): Identifies the type of SRv6
service information. It is assigned values from the IANA Registry service information. It is assigned values from the IANA Registry
"SRv6 Service Sub-TLV Types". "SRv6 Service Sub-TLV Types".
o SRv6 Service Sub-TLV Length (2 octets): Specifies the total length o SRv6 Service Sub-TLV Length (2 octets): Specifies the total length
of the Sub-TLV Value field. of the Sub-TLV Value field.
o SRv6 Service Sub-TLV Value (variable): Contains data specific to o SRv6 Service Sub-TLV Value (variable): Contains data specific to
the Sub-TLV Type. In addition to fixed length data, this may also the Sub-TLV Type. In addition to fixed length data, it contains
optionally contain other properties of the SRv6 Service encoded as other properties of the SRv6 Service encoded as a set of SRv6
a set of SRv6 Service Data Sub-Sub-TLVs whose format is described Service Data Sub-Sub-TLVs whose format is described in Section 3.2
in another sub-section below. below.
2.1.1. SRv6 SID Information Sub-TLV 3.1. SRv6 SID Information Sub-TLV
SRv6 Service Sub-TLV Type 1 is assigned for SRv6 SID Information Sub- 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 TLV. This Sub-TLV contains a single SRv6 SID along with its
properties. Its encoding is depicted below: properties. Its encoding is depicted below:
0 1 2 3 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 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 | SRv6 Service | |
| Sub-TLV | Sub-TLV | | | Sub-TLV | Sub-TLV | |
| Type=1 | Length | RESERVED2 | | Type=1 | Length | RESERVED1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID Value (16 bytes) // // SRv6 SID Value (16 bytes) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 SID Flags| SRv6 Endpoint Behavior | RESERVED3 | | SRv6 SID Flags| SRv6 Endpoint Behavior | RESERVED2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Service Data Sub-Sub-TLVs // // SRv6 Service Data Sub-Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to o SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to
represent SRv6 SID Information Sub-TLV. represent SRv6 SID Information Sub-TLV.
o SRv6 Service Sub-TLV Length (2 octets): This field contains the o SRv6 Service Sub-TLV Length (2 octets): This field contains the
total length of the Value field of the Sub-TLV. total length of the Value field of the Sub-TLV.
o RESERVED2 (1 octet): SHOULD be set to 0 by the sender and MUST be o RESERVED1 (1 octet): SHOULD be set to 0 by the sender and MUST be
ignored by the receiver. ignored by the receiver.
o SRv6 SID Value (16 octets): Encodes an SRv6 SID as defined in o SRv6 SID Value (16 octets): Encodes an SRv6 SID as defined in
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
o SRv6 SID Flags (1 octet): Encodes SRv6 SID Flags - none are o SRv6 SID Flags (1 octet): Encodes SRv6 SID Flags - none are
currently defined. currently defined.
o SRv6 Endpoint Behavior (2 octets): Encodes SRv6 Endpoint behavior o SRv6 Endpoint Behavior (2 octets): Encodes SRv6 Endpoint behavior
defined in [I-D.ietf-spring-srv6-network-programming]. This field codepoint value from the IANA registry defined in section 9.2 of
SHOULD be set to the value 0xFFFF indicating opaque behavior [I-D.ietf-spring-srv6-network-programming] that is associated with
unless the router wants to signal the actual behavior. SRv6 SID.
o RESERVED3 (1 octet): SHOULD be set to 0 by the sender and MUST be o RESERVED2 (1 octet): SHOULD be set to 0 by the sender and MUST be
ignored by the receiver. ignored by the receiver.
o SRv6 Service Data Sub-Sub-TLV Value (variable): This field o SRv6 Service Data Sub-Sub-TLV Value (variable): Used to advertise
contains optional properties of the SRv6 SID. It is encoded as a properties of the SRv6 SID. It is encoded as a set of SRv6
set of SRv6 Service Data Sub-Sub-TLVs. Service Data Sub-Sub-TLVs.
2.1.2. SRv6 Service Data Sub-Sub-TLVs 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: The format of the SRv6 Service Data Sub-Sub-TLV is depicted below:
0 1 2 3 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 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 // | Service Data | Sub-Sub-TLV Length |Sub-Sub TLV //
| Sub-Sub-TLV | | Value // | Sub-Sub-TLV | | Value //
| Type | | // | Type | | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o SRv6 Service Data Sub-Sub-TLV Type (1 octet): Identifies the 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 of Sub-Sub-TLV. It is assigned values from the IANA Registry
"SRv6 Service Data Sub-Sub-TLVs". "SRv6 Service Data Sub-Sub-TLVs".
o SRv6 Service Data Sub-Sub-TLV Length (2 octets): Specifies the o SRv6 Service Data Sub-Sub-TLV Length (2 octets): Specifies the
total length of the Sub-Sub-TLV Value field. total length of the Sub-Sub-TLV Value field.
o SRv6 Service Data Sub-Sub-TLV Value (variable): Contains data o SRv6 Service Data Sub-Sub-TLV Value (variable): Contains data
specific to the Sub-Sub-TLV Type. specific to the Sub-Sub-TLV Type.
2.1.2.1. SRv6 SID Structure Sub-Sub-TLV 3.2.1. SRv6 SID Structure Sub-Sub-TLV
SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for SRv6 SID 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 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 advertise the lengths of each individual parts of the SRv6 SID as
defined in [I-D.ietf-spring-srv6-network-programming]. It is carried defined in [I-D.ietf-spring-srv6-network-programming]. It is carried
as Sub-Sub-TLV in SRv6 SID Information Sub-TLV as Sub-Sub-TLV in SRv6 SID Information Sub-TLV
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 51 skipping to change at page 8, line 11
| Transposition | | Transposition |
| Offset | | Offset |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
o SRv6 Service Data Sub-Sub-TLV Type (1 octet): This field is set to o SRv6 Service Data Sub-Sub-TLV Type (1 octet): This field is set to
1 to represent SRv6 SID Structure Sub-Sub-TLV. 1 to represent SRv6 SID Structure Sub-Sub-TLV.
o SRv6 Service Data Sub-Sub-TLV Length (2 octets): This field o SRv6 Service Data Sub-Sub-TLV Length (2 octets): This field
contains the total length of 6 bytes. contains the total length of 6 bytes.
o Locator Block Length(1 octet): Contains length of SRv6 SID locator o Locator Block Length (1 octet): Contains length of SRv6 SID
Block in bits. locator Block in bits.
o Locator Node Length(1 octet): Contains length of SRv6 SID locator o Locator Node Length (1 octet): Contains length of SRv6 SID locator
Node in bits. Node in bits.
o Function Length(1 octet): Contains length of SRv6 SID Function in o Function Length (1 octet): Contains length of SRv6 SID Function in
bits. bits.
o Arguments Length(1 octet): Contains length of SRv6 SID arguments o Argument Length (1 octet): Contains length of SRv6 SID argument in
in bits. bits.
o Transposition Length(1 octet): Size in bits for the part of SID o Transposition Length (1 octet): Size in bits for the part of SID
that has been transposed (or shifted) into a label field that has been transposed (or shifted) into a label field
o Transposition Offset(1 octet): The offset position in bits for the o Transposition Offset (1 octet): The offset position in bits for
part of SID that has been transposed (or shifted) into a label the part of SID that has been transposed (or shifted) into a label
field. field.
Section 5 describes mechanisms for signaling of the SRv6 Service SID Section 4 describes mechanisms for signaling of the SRv6 Service SID
by transposing a variable part of the SRv6 SID value (function and/or by transposing a variable part of the SRv6 SID value (function and/or
the argument parts) and carrying them in existing label fields to the argument parts) and carrying them in existing label fields to
achieve more efficient packing of those service prefix NLRIs in BGP achieve more efficient packing of those service prefix NLRIs in BGP
update messages. The SRv6 SID Structure Sub-Sub-TLV MUST be included update messages. The SRv6 SID Structure Sub-Sub-TLV contains
with the appropriate length fields when the SRv6 Service SID is appropriate length fields when the SRv6 Service SID is signaled in
signaled in split parts to enable the receiver to put together the split parts to enable the receiver to put together the SID
SID accurately. accurately.
Transposition Offset indicates the bit position and Transposition Transposition Offset indicates the bit position and Transposition
Length indicates the number of bits that are being taken out of the 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 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. 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 Transposition Length of 0 indicates nothing is transposed and that
the entire SRv6 SID value is encoded in the SID Information sub-TLV. the entire SRv6 SID value is encoded in the SID Information sub-TLV.
In this case, the Transposition Offset MUST be set to 0. 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 Since size of label field is 24 bits, only that many bits can be
transposed from the SRv6 SID value into it. transposed from the SRv6 SID value into it.
The SRv6 SID Structure Sub-Sub-TLV is optional and MAY be included As an example, when the entire function part of size 16 of an SRv6
when the entire SRv6 Service SID value is encoded in the SID SID is transposed and the sum of the locator block and locator node
Information Sub-TLV. parts is 64, then the transposition offset would be 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 SRv6 SID encoded in 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 Arguments MAY be generally applicable for SIDs of only specific
behaviors (e.g. End.DT2M) and therefore the argument length MUST be behaviors (e.g. End.DT2M) and therefore the argument length MUST be
set to 0 for SIDs where the argument is not applicable. set to 0 for SIDs where the argument is not applicable.
3. BGP based L3 service over SRv6 4. Encoding SRv6 SID information
The SRv6 Service SID(s) for a BGP Service Prefix are carried in the
SRv6 Services TLVs of the BGP Prefix-SID Attribute.
For certain types 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, 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 encoding of
the SRv6 Service SID either as a whole in 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
and Argument parts) in the existing label fields specific to that
service encoding. This later form of encoding is referred to as the
Transposition Scheme where the SRv6 SID Structure Sub-Sub-TLV
describes the sizes of the parts of the SRv6 SID and to also indicate
offset of variable part along with its length in SRv6 SID value. The
use of the Transposition Scheme is RECOMMENDED for the specific
service encodings that allow it as described further in Section 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 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 and Transposition Length indicates the number of
bits that are being taken out of the SID and put into label field.
In yet another example, for the EVPN Per-ES A-D 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 ESI Label field of the ESI Label Extended Community and the SID
value in the SRv6 Services TLV is set to 0 with the SRv6 SID
Structure Sub-Sub-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 transposition offset and length of SID
structure TLV. The receiving router is then able to put together the
entire SRv6 Service SID (e.g. for the End.DT2M behavior) placing the
label value received in the ESI Label field of the Per-ES A-D route
into the correct transposition offset and length in the SRv6 SID with
the End.DT2M behavior received for a EVPN Route Type 3 value.
5. BGP based L3 service over SRv6
BGP egress nodes (egress PEs) advertise a set of reachable prefixes. BGP egress nodes (egress PEs) advertise a set of reachable prefixes.
Standard BGP update propagation schemes[RFC4271], which may make use Standard BGP update propagation schemes[RFC4271], which may make use
of route reflectors [RFC4456], are used to propagate these prefixes. of route reflectors [RFC4456], are used to propagate these prefixes.
BGP ingress nodes (ingress PEs) receive these advertisements and may BGP ingress nodes (ingress PEs) receive these advertisements and may
add the prefix to the RIB in an appropriate VRF. add the prefix to the RIB in an appropriate VRF.
Egress PEs which supports SRv6 based L3 services advertises overlay Egress PEs which supports SRv6 based L3 services advertises overlay
service prefixes along with a Service SID enclosed in a SRv6 L3 service prefixes along with a Service SID enclosed in a SRv6 L3
Service TLV within the BGP Prefix-SID Attribute. This TLV serves two Service TLV within the BGP Prefix-SID Attribute. This TLV serves two
purposes - first, it indicates that the egress PE is reachable via an purposes - first, it indicates that the egress PE supports SRv6
SRv6 underlay and the BGP ingress PE receiving this route MUST choose overlay and the BGP ingress PE receiving this route MUST choose to
to perform IPv6 encapsulation and optionally insert an SRH when perform IPv6 encapsulation and optionally insert an SRH when
required; second ,it indicates the value of the Service SID to be required; second ,it indicates the value of the Service SID to be
used in the encapsulation. used in the encapsulation.
The Service SID thus signaled only has local significance at the 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 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 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) specific Address Family table (END.DT) or next-hop/interface (END.DX)
as defined in [I-D.ietf-spring-srv6-network-programming]. as defined in [I-D.ietf-spring-srv6-network-programming].
The SRv6 Service SID SHOULD be routable within the AS of the egress The SRv6 Service SID SHOULD be routable within the AS of the egress
PE and serves the dual purpose of providing reachability between PE and serves the dual purpose of providing reachability between
ingress PE and egress PE while also encoding the endpoint behavior. 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 At an ingress PE, BGP installs the received prefix in the correct RIB
table, recursing via an SR Policy leveraging the received SRv6 table, recursing via an SR Policy leveraging the received SRv6
Service SID. Service SID.
Assuming best-effort connectivity to the egress PE, the SR policy has Assuming best-effort connectivity to the egress PE, the ingress PE
a path with a SID list made up of a single SID - the SRv6 Service SID encapsulates the payload in an outer IPv6 header where the
received with the related BGP route update. destination address is the SRv6 Service SID associated with the
related BGP route update.
However, when the received route is colored with an extended color However, when the received route is colored with an extended color
community 'C' and Next-Hop 'N', and the ingress PE has a valid SRv6 community 'C' and Next-Hop 'N', and the ingress PE has a valid SRv6
Policy (C, N) associated with SID list <S1,S2, S3> [I-D.filsfils- Policy (C, N) associated with SID list <S1,S2, S3>
spring-segment-routing-policy], then the effective SR Policy is <S1, [I-D.ietf-spring-segment-routing-policy], then the effective SR
S2, S3-Service-SID>. Policy is <S1, S2, S3-Service-SID>.
Multiple VPN routes MAY resolve recursively via the same SR Policy. Multiple VPN routes MAY resolve recursively via the same SR Policy.
3.1. IPv4 VPN Over SRv6 Core 5.1. IPv4 VPN Over SRv6 Core
The MP_REACH_NLRI for SRv6 core is encoded according to IPv4 VPN Over The MP_REACH_NLRI for SRv6 core is encoded according to IPv4 VPN Over
IPv6 Core defined in [RFC5549]. IPv6 Core defined in [I-D.ietf-bess-rfc5549revision].
Label field of IPv4-VPN NLRI is set to Implicit NULL when the SID Label field of IPv4-VPN NLRI carries the Function part of the SRv6
Structure Sub-Sub-TLV is not present or when it is present and SID when the Transposition Scheme of encoding (Section 4) is used and
indicates that the Function is encoded in the SID value (refer otherwise set to Implicit NULL.
Section 5 for details). Otherwise it carries the Function part of
SRv6 SID when indicated as such by the SID Structure Sub-Sub-TLV.
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 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 behavior of the SRv6 SID is entirely up to the originator of the
advertisement. In practice, the behavior SHOULD be End.DX4 or advertisement. In practice, the behavior is End.DX4 or End.DT4.
End.DT4.
3.2. IPv6 VPN Over SRv6 Core 5.2. IPv6 VPN Over SRv6 Core
The MP_REACH_NLRI for SRv6 core is encoded according to IPv6 VPN over The MP_REACH_NLRI for SRv6 core is encoded according to IPv6 VPN over
IPv6 Core is defined in [RFC4659]. IPv6 Core is defined in [RFC4659].
Label field set to Implicit NULL when the SID Structure Sub-Sub-TLV Label field of the IPv6-VPN NLRI carries the Function part of the
is not present or when it is present and indicates that the Function SRv6 SID when the Transposition Scheme of encoding (Section 4) is
is encoded in the SID value (refer Section 5 for details). Otherwise used and otherwise set to Implicit NULL.
it carries the Function part of SRv6 SID when indicated as such by
the SID Structure Sub-Sub-TLV.
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 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 behavior of the SRv6 SID is entirely up to the originator of the
advertisement. In practice, the behavior SHOULD be End.DX6 or advertisement. In practice, the behavior is End.DX6 or End.DT6.
End.DT6.
3.3. Global IPv4 over SRv6 Core 5.3. Global IPv4 over SRv6 Core
The MP_REACH_NLRI for SRv6 core is encoded according to IPv4 over The MP_REACH_NLRI for SRv6 core is encoded according to IPv4 over
IPv6 Core is defined in [RFC5549]. IPv6 Core is defined in [I-D.ietf-bess-rfc5549revision].
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 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 behavior of the SRv6 SID is entirely up to the originator of the
advertisement. In practice, the behavior SHOULD be End.DX4 or advertisement. In practice, the behavior is End.DX4 or End.DT4.
End.DT4.
3.4. Global IPv6 over SRv6 Core 5.4. Global IPv6 over SRv6 Core
The MP_REACH_NLRI for SRv6 core is encoded according to [RFC2545] The MP_REACH_NLRI for SRv6 core is encoded according to [RFC2545]
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 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 behavior of the SRv6 SID is entirely up to the originator of the
advertisement. In practice, the behavior SHOULD be End.DX6 or advertisement. In practice, the behavior is End.DX6 or End.DT6.
End.DT6.
Also, by utilizing the SRv6 L3 Service TLV to encode the Global SID,
a BGP free core is possible by encapsulating all BGP traffic from
edge to edge over SRv6 dataplane.
4. BGP based Ethernet VPN (EVPN) over SRv6 6. BGP based Ethernet VPN (EVPN) over SRv6
Ethernet VPN(EVPN), as defined in [RFC7432] provides an extendable [RFC7432] provides an extendable method of building an Ethernet VPN
method of building an EVPN overlay. It primarily focuses on MPLS (EVPN) overlay. It primarily focuses on MPLS based EVPNs and
based EVPNs but calls out the extensibility to IP based EVPN [RFC8365] extends to IP based EVPN overlays. [RFC7432] defines Route
overlays. [RFC7432] defines 4 Route Types which carry prefixes and Types 1, 2 and 3 which carry prefixes and MPLS Label fields; the
MPLS Label fields; the Label fields have specific use for MPLS Label fields have specific use for MPLS encapsulation of EVPN
encapsulation of EVPN traffic. Route Type 5 carrying MPLS label traffic. Route Type 5 carrying MPLS label information (and thus
information (and thus encapsulation information) for EVPN is defined encapsulation information) for EVPN is defined in
in [I-D.ietf-bess-evpn-prefix-advertisement]. Route Types 6, 7 and 8 [I-D.ietf-bess-evpn-prefix-advertisement]. Route Types 6,7 and 8 are
are defined in [I-D.ietf-bess-evpn-igmp-mld-proxy]. defined in [I-D.ietf-bess-evpn-igmp-mld-proxy].
o Ethernet Auto-discovery Route (Route Type 1) o Ethernet Auto-discovery Route (Route Type 1)
o MAC/IP Advertisement Route (Route Type 2) o MAC/IP Advertisement Route (Route Type 2)
o Inclusive Multicast Ethernet Tag Route (Route Type 3) o Inclusive Multicast Ethernet Tag Route (Route Type 3)
o Ethernet Segment route (Route Type 4) o Ethernet Segment route (Route Type 4)
o IP prefix route (Route Type 5) o IP prefix route (Route Type 5)
skipping to change at page 11, line 41 skipping to change at page 13, line 5
o Selective Multicast Ethernet Tag route (Route Type 6) o Selective Multicast Ethernet Tag route (Route Type 6)
o IGMP join sync route (Route Type 7) o IGMP join sync route (Route Type 7)
o IGMP leave sync route (Route Type 8) o IGMP leave sync route (Route Type 8)
To support SRv6 based EVPN overlays, one or more SRv6 Service SIDs To support SRv6 based EVPN overlays, one or more SRv6 Service SIDs
are advertised with Route Type 1,2,3 and 5. The SRv6 Service SID(s) are advertised with Route Type 1,2,3 and 5. The SRv6 Service SID(s)
per Route Type are advertised in SRv6 L3/L2 Service TLVs within the per Route Type are advertised in SRv6 L3/L2 Service TLVs within the
BGP Prefix-SID Attribute. Signaling of SRv6 Service SID(s) serves BGP Prefix-SID Attribute. Signaling of SRv6 Service SID(s) serves
two purposes - first, it indicates that the BGP egress device is two purposes - first, it indicates that the BGP egress device
reachable via an SRv6 underlay and the BGP ingress device receiving supports SRv6 overlay and the BGP ingress device receiving this route
this route MUST choose to perform IPv6 encapsulation and optionally MUST perform IPv6 encapsulation and optionally insert an SRH when
insert an SRH when required; second, it indicates the value of the required; second, it indicates the value of the Service SID(s) to be
Service SID(s) to be used in the encapsulation. used in the encapsulation.
4.1. Ethernet Auto-discovery route over SRv6 Core 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.
6.1. Ethernet Auto-discovery route over SRv6 Core
Ethernet Auto-Discovery (A-D) routes are Route Type 1 defined in Ethernet Auto-Discovery (A-D) routes are Route Type 1 defined in
[RFC7432]and may be used to achieve split horizon filtering, fast [RFC7432] and may be used to achieve split horizon filtering, fast
convergence and aliasing. EVPN Route Type 1 is also used in EVPN- convergence and aliasing. EVPN Route Type 1 is also used in EVPN-
VPWS as well as in EVPN flexible cross-connect; mainly used to VPWS as well as in EVPN flexible cross-connect; mainly used to
advertise point-to-point services ID. advertise point-to-point services ID.
Multi-homed PEs MAY advertise an Ethernet Auto-Discovery route per As a reminder, EVPN Route Type 1 is encoded as follows:
Ethernet segment along with the ESI Label extended community defined
in [RFC7432]. PEs may identify other PEs connected to the same
Ethernet segment after the EVPN Route Type 4 ES route exchange. All
the multi-homed and remote PEs that are part of same EVI may import
the Auto-Discovery route.
EVPN Route Type 1 is encoded as follows for SRv6 Core:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
|Ethernet Segment Identifier (10 octets)| |Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| MPLS label (3 octets) | | MPLS label (3 octets) |
+---------------------------------------+ +---------------------------------------+
4.1.1. Per-ES A-D route 6.1.1. Per-ES A-D route
Per-ES A-D route for SRv6 overlay is advertised as follows:
o BGP next-hop: IPv6 address of an egress PE o BGP next-hop: IPv6 address of an egress PE
o Ethernet Tag ID: set to MAX-ET per [RFC7432] section 8.2.1 o Ethernet Tag ID: set as per [RFC7432]
o MPLS Label: always set to zero per [RFC7432] section 8.2.1 o MPLS Label: set as per [RFC7432]
o ESI label extended community ESI label field: It is set to o ESI label extended community ESI label field: carries the Argument
Implicit NULL when the SID Structure Sub-Sub-TLV is not present or part of the SRv6 SID when ESI filtering approach is used along
when it is present and indicates that the Argument is encoded in with the Transposition Scheme of encoding (Section 4) and
the SID value (refer Section 5 for details). Otherwise it carries otherwise set to Implicit NULL.
the Argument part of SRv6 SID when indicated as such by the SID
Structure Sub-Sub-TLV.
A Service SID enclosed in a SRv6 L2 Service TLV within the BGP 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 Prefix-SID attribute is advertised along with the A-D route. The
behavior of the Service SID thus signaled is entirely up to the behavior of the Service SID thus signaled is entirely up to the
originator of the advertisement. The Service SID is used to signal originator of the advertisement. When ESI filtering approach is
Arg.FE2 SID argument for applicable End.DT2M SIDs. used, the 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 of value 0.
4.1.2. Per-EVI A-D route 6.1.2. Per-EVI A-D route
Per-EVI A-D route for SRv6 overlay is advertised as follows:
o BGP next-hop: IPv6 address of an egress PE o BGP next-hop: IPv6 address of an 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 the SID Structure Sub- o Ethernet Tag ID: Set as per [RFC7432], [RFC8214] and
Sub-TLV is not present or when it is present and indicates that [I-D.ietf-bess-evpn-vpws-fxc]
the Function is encoded in the SID value (refer Section 5 for
details). Otherwise it carries the Function part of SRv6 SID when o MPLS Label: carries the Function part of the SRv6 SID when the
indicated as such by the SID Structure Sub-Sub-TLV. Transposition Scheme of encoding (Section 4) is used and otherwise
set to Implicit NULL.
A Service SID enclosed in a SRv6 L2 Service TLV within the BGP 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 Prefix-SID attribute is advertised along with the A-D route. The
behavior of the Service SID thus signaled is entirely up to the behavior of the Service SID thus signaled is entirely up to the
originator of the advertisement. In practice, the behavior would originator of the advertisement. In practice, the behavior is
SHOULD be END.DX2, END.DX2V or END.DT2U. END.DX2, END.DX2V or END.DT2U.
4.2. MAC/IP Advertisement route over SRv6 Core 6.2. MAC/IP Advertisement route over SRv6 Core
EVPN Route Type 2 is used to advertise unicast traffic MAC+IP address EVPN Route Type 2 is used to advertise unicast traffic MAC+IP address
reachability through MP-BGP to all other PEs in a given EVPN reachability through MP-BGP to all other PEs in a given EVPN
instance. instance.
EVPN Route Type 2 is encoded as follows for SRv6 Core: As a reminder, EVPN Route Type 2 is encoded as follows:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
|Ethernet Segment Identifier (10 octets)| |Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| MAC Address Length (1 octet) | | MAC Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
skipping to change at page 13, line 49 skipping to change at page 15, line 27
+---------------------------------------+ +---------------------------------------+
| IP Address (0, 4, or 16 octets) | | IP Address (0, 4, or 16 octets) |
+---------------------------------------+ +---------------------------------------+
| MPLS Label1 (3 octets) | | MPLS Label1 (3 octets) |
+---------------------------------------+ +---------------------------------------+
| MPLS Label2 (0 or 3 octets) | | MPLS Label2 (0 or 3 octets) |
+---------------------------------------+ +---------------------------------------+
o BGP next-hop: IPv6 address of an egress PE o BGP next-hop: IPv6 address of an egress PE
o MPLS Label1: It is set to Implicit NULL when the SID Structure o MPLS Label1: Is associated with the SRv6 L2 Service TLV. It
Sub-Sub-TLV is not present or when it is present and indicates carries the Function part of the SRv6 SID when the Transposition
that the Function is encoded in the SID value (refer Section 5 for Scheme of encoding (Section 4) is used and otherwise set to
details). Otherwise it carries the Function part of SRv6 SID when Implicit NULL.
indicated as such by the SID Structure Sub-Sub-TLV.
o MPLS Label2: It is set to Implicit NULL when the SID Structure o MPLS Label2: Is associated with the SRv6 L3 Service TLV. It
Sub-Sub-TLV is not present or when it is present and indicates carries the Function part of the SRv6 SID when the Transposition
that the Function is encoded in the SID value (refer Section 5 for Scheme of encoding (Section 4) is used and otherwise set to
details). Otherwise it carries the Function part of SRv6 SID when Implicit NULL.
indicated as such by the SID Structure Sub-Sub-TLV.
Service SIDs enclosed in SRv6 L2 Service TLV and optionally in SRv6 Service SIDs enclosed in SRv6 L2 Service TLV and optionally in SRv6
L3 Service TLV within the BGP SID attribute is advertised along with L3 Service TLV within the BGP Prefix-SID attribute is advertised
the MAC/IP Advertisement route. along with the MAC/IP Advertisement route.
Described below are different types of Route Type 2 advertisements. Described below are different types of Route Type 2 advertisements.
o MAC/IP Advertisement route with MAC Only 6.2.1. 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 carries the Function part of SRv6
SID when indicated as such by the SID Structure Sub-Sub-TLV.
o A Service SID enclosed in a SRv6 L2 Service TLV within the BGP o MPLS Label1: Is associated with the SRv6 L2 Service TLV. It
Prefix-SID attribute is advertised along with the route. The carries the Function part of the SRv6 SID when the Transposition
behavior of the Service SID thus signaled is entirely up to the Scheme of encoding (Section 4) is used and otherwise set to
originator of the advertisement. In practice, the behavior SHOULD Implicit NULL.
be END.DX2 or END.DT2U.
o MAC/IP Advertisement route with MAC+IP 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 is entirely up to the
originator of the advertisement. In practice, the behavior is
END.DX2 or END.DT2U.
* BGP next-hop: IPv6 address of egress PE 6.2.2. MAC/IP Advertisement route with MAC+IP
* MPLS Label1: It is set to Implicit NULL when the SID Structure o MPLS Label1: Is associated with the SRv6 L2 Service TLV. It
Sub-Sub-TLV is not present or when it is present and indicates carries the Function part of the SRv6 SID when the Transposition
that the Function is encoded in the SID value(refer Section 5 Scheme of encoding (Section 4) is used and otherwise set to
for details). Otherwise it carries the Function part of SRv6 Implicit NULL.
SID when indicated as such by the SID Structure Sub-Sub-TLV.
* MPLS Label2: It is set to Implicit NULL when the SID Structure o MPLS Label2: Is associated with the SRv6 L3 Service TLV. It
Sub-Sub-TLV is not present or when it is present and indicates carries the Function part of the SRv6 SID when the Transposition
that the Function is encoded in the SID value (refer Section 5 Scheme of encoding (Section 4) is used and otherwise set to
for details). Otherwise it carries the Function part of SRv6 Implicit NULL.
SID when indicated as such by the SID Structure Sub-Sub-TLV.
o An L2 Service SID enclosed in a SRv6 L2 Service TLV within the BGP An L2 Service SID enclosed in a SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the route. In Prefix-SID attribute is advertised along with the route. In
addition, an L3 Service SID enclosed in a SRv6 L3 Service TLV addition, an L3 Service SID enclosed in a SRv6 L3 Service TLV within
within the BGP SID attribute MAY also be advertised along with the the BGP Prefix-SID attribute MAY also be advertised along with the
route. The behavior of the Service SID(s) thus signaled is route. The behavior of the Service SID(s) thus signaled is entirely
entirely up to the originator of the advertisement. In practice, up to the originator of the advertisement. In practice, the behavior
the behavior SHOULD be END.DX2 or END.DT2U for the L2 Service SID, is END.DX2 or END.DT2U for the L2 Service SID, and END.DT6/4 or
and END.DT6/4 or END.DX6/4 for the L3 Service SID. END.DX6/4 for the L3 Service SID.
4.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core 6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core
EVPN Route Type 3 is used to advertise multicast traffic reachability EVPN Route Type 3 is used to advertise multicast traffic reachability
information through MP-BGP to all other PEs in a given EVPN instance. information through MP-BGP to all other PEs in a given EVPN instance.
EVPN Route Type 3 is encoded as follows for SRv6 core: As a reminder, EVPN Route Type 3 is encoded as follows:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Originating Router's IP Address | | Originating Router's IP Address |
| (4 or 16 octets) | | (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
o BGP next-hop: IPv6 address of egress PE o BGP next-hop: IPv6 address of egress PE
PMSI Tunnel Attribute [RFC6514] MAY contain MPLS Implicit NULL label PMSI Tunnel Attribute [RFC6514] is used to identify the P-tunnel used
and Tunnel Type would be similar to that defined in EVPN Route Type 6 for sending BUM traffic. The format of PMSI Tunnel Attribute is
i.e. Ingress replication route. encoded as follows for SRv6 Core:
The format of PMSI Tunnel Attribute is encoded as follows for SRv6
Core:
+---------------------------------------+ +---------------------------------------+
| Flag (1 octet) | | Flag (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Tunnel Type (1 octet) | | Tunnel Type (1 octet) |
+---------------------------------------+ +---------------------------------------+
| MPLS label (3 octet) | | MPLS label (3 octet) |
+---------------------------------------+ +---------------------------------------+
| Tunnel Identifier (variable) | | Tunnel Identifier (variable) |
+---------------------------------------+ +---------------------------------------+
skipping to change at page 16, line 4 skipping to change at page 17, line 16
| Flag (1 octet) | | Flag (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Tunnel Type (1 octet) | | Tunnel Type (1 octet) |
+---------------------------------------+ +---------------------------------------+
| MPLS label (3 octet) | | MPLS label (3 octet) |
+---------------------------------------+ +---------------------------------------+
| Tunnel Identifier (variable) | | Tunnel Identifier (variable) |
+---------------------------------------+ +---------------------------------------+
o Flag: zero value defined per [RFC7432] o Flag: zero value defined per [RFC7432]
o Tunnel Type: defined per [RFC6514] o Tunnel Type: defined per [RFC6514]
o MPLS label: It is set to Implicit NULL when the SID Structure Sub- o MPLS label: It carries the Function part of the SRv6 SID when
Sub-TLV is not present or when it is present and indicates that ingress replication is used and the Transposition Scheme of
the Function is encoded in the SID value (refer Section 5 for encoding (Section 4) is used and otherwise it is set as defined in
details). Otherwise it carries the Function part of SRv6 SID when [RFC6514]
indicated as such by the SID Structure Sub-Sub-TLV.
o Tunnel Identifier: IP address of egress PE o Tunnel Identifier: IP address of egress PE
A Service SID enclosed in a SRv6 L2 Service TLV within the BGP A Service SID enclosed in a SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the route. The Prefix-SID attribute is advertised along with the route. The
behavior of the Service SID thus signaled, is entirely up to the behavior of the Service SID thus signaled, is entirely up to the
originator of the advertisement. In practice, the behavior of the originator of the advertisement. In practice, the behavior of the
SRv6 SID is as follows: SRv6 SID is as follows:
o END.DX2 or END.DT2M behavior o END.DT2M behavior.
o The ESI Filtering argument (Arg.FE2) of the Service SID carried o When ESI-based filtering is used for Multi-Homing or E-Tree
along with EVPN Route Type 1 route SHOULD be merged together with procedures, the ESI Filtering argument (Arg.FE2) of the Service
the applicable End.DT2M SID of Type 3 route advertised by remote SID carried along with EVPN Route Type 1 route SHOULD be merged
PE by doing a bitwise logical-OR operation to create a single SID together with the applicable End.DT2M SID of Type 3 route
on the ingress PE for Split-horizon and other filtering advertised by remote PE by doing a bitwise logical-OR operation to
mechanisms. Details of filtering mechanisms are described in create a single SID on the ingress PE. Details of split-horizon
[RFC7432]. 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].
4.4. Ethernet Segment route over SRv6 Core o When "local-bias" is used as the Multi-Homing 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" procedures are described in [RFC8365].
An Ethernet Segment route i.e. EVPN Route Type 4 is encoded as The setup of multicast trees for use as P-tunnels is outside the
follows for SRv6 core: 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) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Originating Router's IP Address | | Originating Router's IP Address |
| (4 or 16 octets) | | (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
o BGP next-hop: IPv6 address of egress PE o BGP next-hop: IPv6 address of egress PE
SRv6 Service TLVs within BGP SID attribute are not advertised along SRv6 Service TLVs within BGP Prefix-SID attribute are not advertised
with this route. The processing of the route has not changed - it along with this route. The processing of the route has not changed -
remains as described in [RFC7432]. it remains as described in [RFC7432].
4.5. IP prefix route over SRv6 Core 6.5. IP prefix route over SRv6 Core
EVPN Route Type 5 is used to advertise IP address reachability EVPN Route Type 5 is used to advertise IP address reachability
through MP-BGP to all other PEs in a given EVPN instance. IP address through MP-BGP to all other PEs in a given EVPN instance. IP address
may include host IP prefix or any specific subnet. may include host IP prefix or any specific subnet.
EVPN Route Type 5 is encoded as follows for SRv6 core: As a reminder, EVPN Route Type 5 is encoded as follows:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
|Ethernet Segment Identifier (10 octets)| |Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Prefix Length (1 octet) | | IP Prefix Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| IP Prefix (4 or 16 octets) | | IP Prefix (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
| GW IP Address (4 or 16 octets) | | GW IP Address (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
| MPLS Label (3 octets) | | MPLS Label (3 octets) |
+---------------------------------------+ +---------------------------------------+
o BGP next-hop: IPv6 address of egress PE o BGP next-hop: IPv6 address of egress PE
o MPLS Label: It carries the Function part of the SRv6 SID when the
o MPLS Label: It is set to Implicit NULL when the SID Structure Sub- Transposition Scheme of encoding (Section 4) is used and otherwise
Sub-TLV is not present or when it is present and indicates that set to Implicit NULL.
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.
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The
function of the SRv6 SID is entirely up to the originator of the function of the SRv6 SID is entirely up to the originator of the
advertisement. In practice, the behavior may SHOULD be End.DT4/6 or advertisement. In practice, the behavior is End.DT4/6 or End.DX4/6.
End.DX4/6.
4.6. EVPN multicast routes (Route Types 6, 7, 8) over SRv6 core 6.6. EVPN multicast routes (Route Types 6, 7, 8) over SRv6 core
These routes do not require the advertisement of SRv6 Service TLVs These routes do not require the advertisement of SRv6 Service TLVs
along with them. Similar to EVPN Route Type 4, the BGP Nexthop is along with them. Similar to EVPN Route Type 4, the BGP Nexthop is
equal to the IPv6 address of egress PE. More details may be added in equal to the IPv6 address of egress PE.
future revisions of this document.
5. Encoding SRv6 SID information
The SRv6 Service SID(s) for a BGP Service Prefix are carried in the
SRv6 Services TLVs of the BGP Prefix-SID Attribute.
For certain types 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, 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 in the SRv6
Services TLVs or the encoding of only the common parts of the SRv6
SID (e.g. Locator parts) in the SRv6 Services TLVs and encoding the
variable (e.g. Function and Argument parts) in the existing label
fields specific to that service encoding. The SRv6 SID Structure
Sub-Sub-TLV describes the sizes of the parts of the SRv6 SID. It
also indicate offset of variable part and its length in SRv6 SID
value.
As an example, for the EVPN VPWS service prefix described in section
4.1.2, the function part of the SRv6 SID is encoded in the MPLS Label
field of the NLRI and the SID value in the SRv6 Services TLV carries
only the locator parts with 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
the bit position and Transposition Length indicates the number of
bits that are being taken out of the SID 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 to be signaled.
This argument part of the SRv6 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 the SRv6 SID Structure Sub-Sub-TLV
included. 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 SID structure TLV. The receiving
router is then able to put together the entire SRv6 Service SID (e.g.
for the End.DT2M behavior) placing the label value received in the
ESI Label field of the Per-ES A-D route into the correct
transposition offset and length in the SRv6 SID with the End.DT2M
behavior received for a EVPN Route Type 3 value.
6. Implementation Status 7. Implementation Status
The [I-D.matsushima-spring-srv6-deployment-status] describes the The [I-D.matsushima-spring-srv6-deployment-status] describes the
current deployment and implementation status of SRv6 which also current deployment and implementation status of SRv6 which also
includes the BGP services over SRv6 as specified in this document. includes the BGP services over SRv6 as specified in this document.
7. Error Handling 8. Error Handling
In case of any errors encountered while processing SRv6 Service TLVs, In case of any errors encountered while processing SRv6 Service TLVs,
the details of the error SHOULD be logged for further analysis. the details of the error SHOULD be logged for further analysis.
If multiple instances of SRv6 L3 Service TLV is encountered, all but If multiple instances of SRv6 L3 Service TLV is encountered, all but
the first instance MUST be ignored. the first instance MUST be ignored.
If multiple instances of SRv6 L2 Service TLV is encountered, all but If multiple instances of SRv6 L2 Service TLV is encountered, all but
the first instance MUST be ignored. the first instance MUST be ignored.
An SRv6 Service TLV is considered malformed in the following cases: An SRv6 Service TLV is considered malformed in the following cases:
o the TLV Length is less than 1 o the TLV Length is less than 1
o the TLV Length is inconsistent with the length of BGP SID o the TLV Length is inconsistent with the length of BGP Prefix-SID
attribute attribute
o atleast one of the constituent Sub-TLVs is malformed o atleast one of the constituent Sub-TLVs is malformed
An SRv6 Service Sub-TLV is considered malformed in the following An SRv6 Service Sub-TLV is considered malformed in the following
cases: cases:
o the Sub-TLV Length is inconsistent with the length of the o the Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 Service TLV enclosing SRv6 Service TLV
skipping to change at page 20, line 14 skipping to change at page 20, line 24
o the Sub-Sub-TLV Length is inconsistent with the length of the o the Sub-Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 service Sub-TLV enclosing SRv6 service Sub-TLV
Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because
its Type is unrecognized. its Type is unrecognized.
Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because
of failing any semantic validation of its Value field. of failing any semantic validation of its Value field.
The BGP Prefix-SID attribute is considered malformed if it contains SRv6 overlay service requires Service SID for forwarding. The treat-
atleast one constituent SRv6 Service TLV that is malformed. In such as-withdraw action [RFC7606] MUST be performed when at least one
cases, the attribute MUST be discarded [RFC7606]and not propagated malformed SRV6 Service TLV is present in the BGP Prefix-SID
further. Note that if a path whose BGP Prefix-SID attribute is attribute.
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 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 Sub-Sub-TLV transposition length is greater than 24 or addition of
addition of transposition offset and length is greater than 128. transposition offset and length is greater than 128. Path having
Path pointing to such Prefix-SID Attribute should be ineligible such Prefix-SID Attribute should be ineligible during the selection
during the selection of best path for the corresponding prefix. 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, any unrecognized
Sub-TLVs and Sub-Sub-TLVs MUST NOT be propagated.
o if the nexthop is changed during advertisement, the TLVs, Sub-TLVs 9. IANA Considerations
and Sub-Sub-TLVs SHOULD be re-originated if appropriate, and not
merely propagated unchanged. The interpretation of the meaning of
re-origination versus propagation is a matter of local
implementation.
8. IANA Considerations 9.1. BGP Prefix-SID TLV Types registry
8.1. BGP Prefix-SID TLV Types registry
This document defines two new TLV Types of the BGP Prefx-SID This document defines two new TLV Types of the BGP Prefix-SID
attribute. IANA is requested to assign Type values in the registry attribute. IANA is requested to assign Type values in the registry
"BGP Prefix-SID TLV Types" as follows: "BGP Prefix-SID TLV Types" as follows:
Value Type Reference Value Type Reference
-------------------------------------------- --------------------------------------------
[TBD1] SRv6 L3 Service TLV <this document> 4 Deprecated <this document>
[TBD2] SRv6 L2 Service TLV <this document> TBD1 SRv6 L3 Service TLV <this document>
TBD2 SRv6 L2 Service TLV <this document>
IANA is also requested to reserve the following Type value. This was
used in some implementations of previous versions of this draft.
Value Type Reference The value 4 previously corresponded to the SRv6-VPN SID TLV, which
-------------------------------------------- was specified in previous versions of this document and used by early
4 Reserved <this document> implementations of this specification. It was deprecated and
replaced by the SRv6 L3 Service and SRv6 L2 Service TLVs.
8.2. SRv6 Service Sub-TLV Types registry 9.2. SRv6 Service Sub-TLV Types registry
IANA is requested to create and maintain a new registry called "SRv6 IANA is requested to create and maintain a new registry called "SRv6
Service Sub-TLV Types". The allocation policy for this registry is: Service Sub-TLV Types". The allocation policy for this registry is:
0 : Reserved 0 : Reserved
1-127 : IETF Review 1-127 : IETF Review
128-254 : First Come First Served 128-254 : First Come First Served
255 : Reserved 255 : Reserved
The following Sub-TLV Types are defined in this document: The following Sub-TLV Types are defined in this document:
Value Type Reference Value Type Reference
---------------------------------------------------- ----------------------------------------------------
1 SRv6 SID Information Sub-TLV <this document> 1 SRv6 SID Information Sub-TLV <this document>
8.3. SRv6 Service Data Sub-Sub-TLV Types registry 9.3. SRv6 Service Data Sub-Sub-TLV Types registry
IANA is requested to create and maintain a new registry called "SRv6 IANA is requested to create and maintain a new registry called "SRv6
Service Data Sub-Sub-TLV Types". The allocation policy for this Service Data Sub-Sub-TLV Types". The allocation policy for this
registry is: registry is:
0 : Reserved 0 : Reserved
1-127 : IETF Review 1-127 : IETF Review
128-254 : First Come First Served 128-254 : First Come First Served
255 : Reserved 255 : Reserved
The following Sub-Sub-TLV Types are defined in this document: The following Sub-Sub-TLV Types are defined in this document:
Value Type Reference Value Type Reference
---------------------------------------------------- ----------------------------------------------------
1 SRv6 SID Structure Sub-Sub-TLV <this document> 1 SRv6 SID Structure Sub-Sub-TLV <this document>
9. Security Considerations 10. Security Considerations
This document introduces no new security considerations beyond those This document introduces no new security considerations beyond those
already specified in [RFC4271] and [RFC8277]. already specified in [RFC4271].
10. Conclusions
This document proposes extensions to the BGP to allow advertising
certain attributes and functionalities related to SRv6.
11. References
11.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 Prefix SID extensions for
BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress),
June 2018.
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain,
D., and S. Lin, "Advertising Segment Routing Policies in
BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in
progress), July 2019.
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for
Segment Routing", draft-ietf-isis-segment-routing-
extensions-25 (work in progress), May 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-02 (work in progress),
October 2019.
[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>.
[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. Rosen, "Advertising IPv4 Network
Layer Reachability Information with an IPv6 Next Hop",
RFC 5549, DOI 10.17487/RFC5549, May 2009,
<https://www.rfc-editor.org/info/rfc5549>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 11. Acknowledgments
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., The authors of this document would like to thank Stephane Litkowski,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Rishabh Parekh and Xiejingrong for their comments and review of this
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, document.
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Appendix A. Contributors 12. Contributors
Satoru Matsushima Satoru Matsushima
SoftBank SoftBank
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Dirk Steinberg Dirk Steinberg
Steinberg Consulting Steinberg Consulting
Email: dws@steinberg.net Email: dws@steinberg.net
skipping to change at page 26, line 40 skipping to change at page 23, line 29
Zafar Ali Zafar Ali
Cisco Cisco
Email: zali@cisco.com Email: zali@cisco.com
Ketan Talaulikar Ketan Talaulikar
Cisco Cisco
Email: ketant@cisco.com Email: ketant@cisco.com
13. References
13.1. Normative References
[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-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-bess-evpn-vpws-fxc]
Sajassi, A., Brissette, P., Uttaro, J., Drake, J., Lin,
W., Boutros, S., and J. Rabadan, "EVPN VPWS Flexible
Cross-Connect Service", draft-ietf-bess-evpn-vpws-fxc-01
(work in progress), June 2019.
[I-D.ietf-bess-rfc5549revision]
Litkowski, S., Agrawal, S., ananthamurthy, k., and K.
Patel, "Advertising IPv4 Network Layer Reachability
Information with an IPv6 Next Hop", draft-ietf-bess-
rfc5549revision-03 (work in progress), February 2020.
[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-10 (work in
progress), 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>.
[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>.
[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>.
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 Authors' Addresses
Gaurav Dawra (editor) Gaurav Dawra (editor)
LinkedIn LinkedIn
USA USA
Email: gdawra.ietf@gmail.com Email: gdawra.ietf@gmail.com
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Robert Raszuk Robert Raszuk
Bloomberg LP Bloomberg LP
USA USA
Email: robert@raszuk.net Email: robert@raszuk.net
Bruno Decraene Bruno Decraene
Orange Orange
France France
 End of changes. 119 change blocks. 
518 lines changed or deleted 523 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/