< draft-ietf-spring-srv6-network-programming-00.txt   draft-ietf-spring-srv6-network-programming-01.txt >
SPRING C. Filsfils SPRING C. Filsfils
Internet-Draft P. Camarillo, Ed. Internet-Draft P. Camarillo, Ed.
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: October 26, 2019 J. Leddy Expires: January 4, 2020 J. Leddy
Comcast Individual Contributor
D. Voyer D. Voyer
Bell Canada Bell Canada
S. Matsushima S. Matsushima
SoftBank SoftBank
Z. Li Z. Li
Huawei Technologies Huawei Technologies
April 24, 2019 July 3, 2019
SRv6 Network Programming SRv6 Network Programming
draft-ietf-spring-srv6-network-programming-00 draft-ietf-spring-srv6-network-programming-01
Abstract Abstract
This document describes the SRv6 network programming concept and its This document describes the SRv6 network programming concept and its
most basic functions. most basic functions.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 October 26, 2019. This Internet-Draft will expire on January 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . . . 5 3. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Functions associated with a SID . . . . . . . . . . . . . . . 7 4. Functions associated with a SID . . . . . . . . . . . . . . . 7
4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 8 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 8
4.2. End.X: Layer-3 cross-connect . . . . . . . . . . . . . . 8 4.2. End.X: Layer-3 cross-connect . . . . . . . . . . . . . . 9
4.3. End.T: Specific IPv6 table lookup . . . . . . . . . . . . 9 4.3. End.T: Specific IPv6 table lookup . . . . . . . . . . . . 10
4.4. End.DX2: Decapsulation and L2 cross-connect . . . . . . . 10 4.4. End.DX2: Decapsulation and L2 cross-connect . . . . . . . 10
4.5. End.DX2V: Decapsulation and VLAN L2 table lookup . . . . 11 4.5. End.DX2V: Decapsulation and VLAN L2 table lookup . . . . 11
4.6. End.DT2U: Decapsulation and unicast MAC L2 table lookup . 11 4.6. End.DT2U: Decapsulation and unicast MAC L2 table lookup . 12
4.7. End.DT2M: Decapsulation and L2 table flooding . . . . . . 12 4.7. End.DT2M: Decapsulation and L2 table flooding . . . . . . 12
4.8. End.DX6: Decapsulation and IPv6 cross-connect . . . . . . 13 4.8. End.DX6: Decapsulation and IPv6 cross-connect . . . . . . 13
4.9. End.DX4: Decapsulation and IPv4 cross-connect . . . . . . 14 4.9. End.DX4: Decapsulation and IPv4 cross-connect . . . . . . 14
4.10. End.DT6: Decapsulation and specific IPv6 table lookup . . 15 4.10. End.DT6: Decapsulation and specific IPv6 table lookup . . 15
4.11. End.DT4: Decapsulation and specific IPv4 table lookup . . 15 4.11. End.DT4: Decapsulation and specific IPv4 table lookup . . 15
4.12. End.DT46: Decapsulation and specific IP table lookup . . 16 4.12. End.DT46: Decapsulation and specific IP table lookup . . 16
4.13. End.B6.Insert: Endpoint bound to an SRv6 policy . . . . . 17 4.13. End.B6.Insert: Endpoint bound to an SRv6 policy . . . . . 17
4.14. End.B6.Insert.Red: [...] with reduced SRH insertion . . . 18 4.14. End.B6.Insert.Red: [...] with reduced SRH insertion . . . 18
4.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 18 4.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 18
4.16. End.B6.Encaps.Red: [...] with reduced SRH insertion . . . 19 4.16. End.B6.Encaps.Red: [...] with reduced SRH insertion . . . 19
skipping to change at page 3, line 23 skipping to change at page 3, line 23
7. Basic security for intra-domain deployment . . . . . . . . . 29 7. Basic security for intra-domain deployment . . . . . . . . . 29
7.1. SEC-1 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. SEC-1 . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2. SEC-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2. SEC-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. SEC-3 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3. SEC-3 . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 31 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 31
8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10. Work in progress . . . . . . . . . . . . . . . . . . . . . . 36 10. Work in progress . . . . . . . . . . . . . . . . . . . . . . 35
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
13.1. Normative References . . . . . . . . . . . . . . . . . . 39 13.1. Normative References . . . . . . . . . . . . . . . . . . 38
13.2. Informative References . . . . . . . . . . . . . . . . . 39 13.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Segment Routing leverages the source routing paradigm. An ingress Segment Routing leverages the source routing paradigm. An ingress
node steers a packet through a ordered list of instructions, called node steers a packet through a ordered list of instructions, called
segments. Each one of these instructions represents a function to be segments. Each one of these instructions represents a function to be
called at a specific location in the network. A function is locally called at a specific location in the network. A function is locally
defined on the node where it is executed and may range from simply defined on the node where it is executed and may range from simply
moving forward in the segment list to any complex user-defined moving forward in the segment list to any complex user-defined
behavior. The network programming consists in combining segment behavior. The network programming consists in combining segment
skipping to change at page 6, line 21 skipping to change at page 6, line 21
This information is stored in the "My SID Table". The "My SID Table" This information is stored in the "My SID Table". The "My SID Table"
has three main purposes: has three main purposes:
- Define which SIDs are explicitly instantiated on that node - Define which SIDs are explicitly instantiated on that node
- Specify which instruction is bound to each of the instantiated SIDs - Specify which instruction is bound to each of the instantiated SIDs
- Store the parameters associated with such instruction (i.e. OIF, - Store the parameters associated with such instruction (i.e. OIF,
NextHop, VRF,...) NextHop, VRF,...)
We represent an SRv6 SID as LOC:FUNCT where LOC is the L most We represent an SRv6 SID as LOC:FUNCT where LOC (locator) is the L
significant bits and FUNCT is the 128-L least significant bits. L is most significant bits and FUNCT (function) is the 128-L least
called the locator length and is flexible. Each operator is free to significant bits. L is called the locator length and is flexible.
use the locator length it chooses. Most often the LOC part of the Each operator is free to use the locator length it chooses. Most
SID is routable and leads to the node which instantiates that SID. often the locator is routable and leads to the node which
instantiates that SID. A control-plane protocol might represent the
locator as B:N where B is the SRv6 SID block (IPv6 subnet allocated
for SRv6 SIDs by the operator) and N is the identifier of the parent
node.
The FUNCT part of the SID is an opaque identification of a local The function part of the SID is an opaque identification of a local
function bound to the SID. The FUNCT value zero is invalid. function bound to the SID. The FUNCT value zero is invalid.
Often, for simplicity of illustration, we will use a locator length Often, for simplicity of illustration, we will use a locator length
of 32 bits. This is just an example. Implementations must not of 32 bits. This is just an example. Implementations must not
assume any a priori prefix length. assume any a priori prefix length.
A function may require additional arguments that would be placed A function may require additional arguments that would be placed
immediately after the FUNCT. In such case, the SRv6 SID will have immediately after the FUNCT. In such case, the SRv6 SID will have
the form LOC:FUNCT:ARGS::. For this reason, the "My SID Table" the form LOC:FUNCT:ARGS::. For this reason, the "My SID Table"
matches on a per longest-prefix-match basis. matches on a per longest-prefix-match basis.
skipping to change at page 8, line 43 skipping to change at page 8, line 43
Ref3: ICMP error is sent to the source address with error code (TBD Ref3: ICMP error is sent to the source address with error code (TBD
by IANA) "SR Upper-layer Header Error" and pointer set to the NH. by IANA) "SR Upper-layer Header Error" and pointer set to the NH.
A local SID could be bound to a function which authorizes the A local SID could be bound to a function which authorizes the
decapsulation of an outer header (e.g. IPinIP) or the punting of the decapsulation of an outer header (e.g. IPinIP) or the punting of the
packet to TCP, UDP or any other protocol. This however needs to be packet to TCP, UDP or any other protocol. This however needs to be
explicitly defined in the function bound to the local SID. By explicitly defined in the function bound to the local SID. By
default, a local SID bound to the well-known function "End"neither default, a local SID bound to the well-known function "End"neither
allows the decapsulation of an outer header nor the cleanup of an allows the decapsulation of an outer header nor the cleanup of an
SRH. As a consequence, an End SID cannot be the last SID of an SRH SRH. As a consequence, an End SID is not the last SID of an SRH or
and cannot be the DA of a packet without SRH. the DA of a packet without SRH, unless combined with the flavours
defined in Section 4.21.
This is the SRv6 instantiation of a Prefix SID [RFC8402]. This is the SRv6 instantiation of a Prefix SID [RFC8402].
4.2. End.X: Layer-3 cross-connect 4.2. End.X: Layer-3 cross-connect
The "Endpoint with cross-connect to an array of layer-3 adjacencies" The "Endpoint with cross-connect to an array of layer-3 adjacencies"
function (End.X for short) is a variant of the End function. function (End.X for short) is a variant of the End function.
When N receives a packet destined to S and S is a local End.X SID, N When N receives a packet destined to S and S is a local End.X SID, N
does: does:
skipping to change at page 10, line 42 skipping to change at page 10, line 50
3. ELSE IF ENH=59 ;; Ref2 3. ELSE IF ENH=59 ;; Ref2
4. pop the (outer) IPv6 header and its extension headers 4. pop the (outer) IPv6 header and its extension headers
5. forward the resulting frame to OIF bound to the SID S 5. forward the resulting frame to OIF bound to the SID S
6. ELSE 6. ELSE
7. Send an ICMP parameter problem message ;; Ref3 7. Send an ICMP parameter problem message ;; Ref3
8. drop the packet 8. drop the packet
Ref1: An End.DX2 SID must always be the last SID, or it can be the Ref1: An End.DX2 SID must always be the last SID, or it can be the
Destination Address of an IPv6 packet with no SRH header. Destination Address of an IPv6 packet with no SRH header.
Ref2: We conveniently reuse the next-header value 59 allocated to Ref2: The next-header value 59 (IPv6 No Next Header [RFC8200])
IPv6 No Next Header [RFC8200]. When the SID corresponds to function identifies that there is no further Internet Protocol header to be
processed in the packet. When the SID corresponds to function
End.DX2 and the Next-Header value is 59, we know that an Ethernet End.DX2 and the Next-Header value is 59, we know that an Ethernet
frame is in the payload without any further header. frame is in the payload without any further header.
Ref3: ICMP error is sent to the source address with error code (TBD Ref3: ICMP error is sent to the source address with error code (TBD
by IANA) "SR Upper-layer Header Error" and pointer set to the NH. by IANA) "SR Upper-layer Header Error" and pointer set to the NH.
An End.DX2 function could be customized to expect a specific VLAN An End.DX2 function could be customized to expect a specific VLAN
format and rewrite the egress VLAN header before forwarding on the format and rewrite the egress VLAN header before forwarding on the
outgoing interface. outgoing interface.
skipping to change at page 11, line 29 skipping to change at page 11, line 38
4. pop the (outer) IPv6 header and its extension headers 4. pop the (outer) IPv6 header and its extension headers
5. lookup the exposed inner VLANs in L2 table T 5. lookup the exposed inner VLANs in L2 table T
6. forward via the matched table entry 6. forward via the matched table entry
7. ELSE 7. ELSE
8. Send an ICMP parameter problem message ;; Ref3 8. Send an ICMP parameter problem message ;; Ref3
9. drop the packet 9. drop the packet
Ref1: An End.DX2V SID must always be the last SID, or it can be the Ref1: An End.DX2V SID must always be the last SID, or it can be the
Destination Address of an IPv6 packet with no SRH header. Destination Address of an IPv6 packet with no SRH header.
Ref2: We conveniently reuse the next-header value 59 allocated to Ref2: The next-header value 59 (IPv6 No Next Header [RFC8200])
IPv6 No Next Header [RFC8200]. When the SID corresponds to function identifies that there is no further Internet Protocol header to be
End.DX2V and the Next-Header value is 59, we know that an Ethernet processed in the packet. When the SID corresponds to function
End.DX2 and the Next-Header value is 59, we know that an Ethernet
frame is in the payload without any further header. frame is in the payload without any further header.
Ref3: ICMP error is sent to the source address with error code (TBD Ref3: ICMP error is sent to the source address with error code (TBD
by IANA) "SR Upper-layer Header Error" and pointer set to the NH. by IANA) "SR Upper-layer Header Error" and pointer set to the NH.
An End.DX2V function could be customized to expect a specific VLAN An End.DX2V function could be customized to expect a specific VLAN
format and rewrite the egress VLAN header before forwarding on the format and rewrite the egress VLAN header before forwarding on the
outgoing interface. outgoing interface.
The End.DX2V is used for EVPN Flexible cross-connect use-cases. The End.DX2V is used for EVPN Flexible cross-connect use-cases.
skipping to change at page 12, line 22 skipping to change at page 12, line 31
8. forward via the matched table T entry 8. forward via the matched table T entry
9. ELSE 9. ELSE
10. forward via all L2OIF entries in table T 10. forward via all L2OIF entries in table T
11. ELSE 11. ELSE
12. Send an ICMP parameter problem message ;; Ref4 12. Send an ICMP parameter problem message ;; Ref4
13. drop the packet 13. drop the packet
Ref1: An End.DT2U SID must always be the last SID, or it can be the Ref1: An End.DT2U SID must always be the last SID, or it can be the
Destination Address of an IPv6 packet with no SRH header. Destination Address of an IPv6 packet with no SRH header.
Ref2: We conveniently reuse the next-header value 59 allocated to Ref2: The next-header value 59 (IPv6 No Next Header [RFC8200])
IPv6 No Next Header [RFC8200]. When the SID corresponds to function identifies that there is no further Internet Protocol header to be
End.DT2U and the Next-Header value is 59, we know that an Ethernet processed in the packet. When the SID corresponds to function
End.DX2 and the Next-Header value is 59, we know that an Ethernet
frame is in the payload without any further header. frame is in the payload without any further header.
Ref3: In EVPN, the learning of the exposed inner MAC SA is done via Ref3: In EVPN, the learning of the exposed inner MAC SA is done via
control plane. control plane.
Ref4: ICMP error is sent to the source address with error code (TBD Ref4: ICMP error is sent to the source address with error code (TBD
by IANA) "SR Upper-layer Header Error" and pointer set to the NH. by IANA) "SR Upper-layer Header Error" and pointer set to the NH.
The End.DT2U is used for EVPN Bridging unicast use cases. The End.DT2U is used for EVPN Bridging unicast use cases.
skipping to change at page 13, line 18 skipping to change at page 13, line 21
4. pop the (outer) IPv6 header and its extension headers 4. pop the (outer) IPv6 header and its extension headers
3. learn the exposed inner MAC SA in L2 table T ;; Ref3 3. learn the exposed inner MAC SA in L2 table T ;; Ref3
4. forward on all L2OIF excluding the one specified in Arg.FE2 4. forward on all L2OIF excluding the one specified in Arg.FE2
5. ELSE 5. ELSE
6. Send an ICMP parameter problem message ;; Ref4 6. Send an ICMP parameter problem message ;; Ref4
7. drop the packet 7. drop the packet
Ref1: An End.DT2M SID must always be the last SID, or it can be the Ref1: An End.DT2M SID must always be the last SID, or it can be the
Destination Address of an IPv6 packet with no SRH header. Destination Address of an IPv6 packet with no SRH header.
Ref2: We conveniently reuse the next-header value 59 allocated to Ref2: The next-header value 59 (IPv6 No Next Header [RFC8200])
IPv6 No Next Header [RFC8200]. When the SID corresponds to function identifies that there is no further Internet Protocol header to be
End.DT2M and the Next-Header value is 59, we know that an Ethernet processed in the packet. When the SID corresponds to function
End.DX2 and the Next-Header value is 59, we know that an Ethernet
frame is in the payload without any further header. frame is in the payload without any further header.
Ref3: In EVPN, the learning of the exposed inner MAC SA is done via Ref3: In EVPN, the learning of the exposed inner MAC SA is done via
control plane control plane
Ref4: ICMP error is sent to the source address with error code (TBD Ref4: ICMP error is sent to the source address with error code (TBD
by IANA) "SR Upper-layer Header Error" and pointer set to the NH. by IANA) "SR Upper-layer Header Error" and pointer set to the NH.
The End.DT2M is used for EVPN Bridging BUM use-case with ESI The End.DT2M is used for EVPN Bridging BUM use-case with ESI
filtering capability. filtering capability.
skipping to change at page 18, line 7 skipping to change at page 18, line 7
4.13. End.B6.Insert: Endpoint bound to an SRv6 policy 4.13. End.B6.Insert: Endpoint bound to an SRv6 policy
The "Endpoint bound to an SRv6 Policy" is a variant of the End The "Endpoint bound to an SRv6 Policy" is a variant of the End
function. function.
When N receives a packet destined to S and S is a local End.B6.Insert When N receives a packet destined to S and S is a local End.B6.Insert
SID, N does: SID, N does:
1. IF NH=SRH and SL > 0 ;; Ref1 1. IF NH=SRH and SL > 0 ;; Ref1
2. do not decrement SL nor update the IPv6 DA with SRH[SL] 2. do not decrement SL nor update the IPv6 DA with SRH[SL]
3. insert a new SRH, in between the IPv6 header and the 3. insert a new SRH, in between the IPv6 header and the ;; Ref2
received SRH received SRH
4. set the IPv6 DA to the first segment of the SRv6 Policy 4. set the IPv6 DA to the first segment of the SRv6 Policy
5. forward according to the first segment of the SRv6 Policy 5. forward according to the first segment of the SRv6 Policy
6. ELSE 6. ELSE
7. Send an ICMP parameter problem message ;; Ref2 7. Send an ICMP parameter problem message ;; Ref3
8. drop the packet 8. drop the packet
Ref1: An End.B6.Insert SID, by definition, is never the last SID. Ref1: An End.B6.Insert SID, by definition, is never the last SID.
Ref2: ICMP error is sent to the source address with error code (TBD Ref2: [I-D.voyer-6man-extension-header-insertion]
Ref3: ICMP error is sent to the source address with error code (TBD
by IANA) "SR Upper-layer Header Error" and pointer set to the NH. by IANA) "SR Upper-layer Header Error" and pointer set to the NH.
Note: Instead of the term "insert", "push" may also be used. Note: Instead of the term "insert", "push" may also be used.
The End.B6.Insert function is required to express scalable traffic- The End.B6.Insert function is required to express scalable traffic-
engineering policies across multiple domains. This is the SRv6 engineering policies across multiple domains. This is the SRv6
instantiation of a Binding SID [RFC8402]. instantiation of a Binding SID [RFC8402].
4.14. End.B6.Insert.Red: [...] with reduced SRH insertion 4.14. End.B6.Insert.Red: [...] with reduced SRH insertion
skipping to change at page 21, line 38 skipping to change at page 21, line 38
with a setsocksopt system call. with a setsocksopt system call.
4.20. Non SR-aware application 4.20. Non SR-aware application
[I-D.xuclad-spring-sr-service-programming] defines a set of [I-D.xuclad-spring-sr-service-programming] defines a set of
additional functions in order to enable non SR-aware applications to additional functions in order to enable non SR-aware applications to
be associated with an SRv6 SID. be associated with an SRv6 SID.
4.21. Flavours 4.21. Flavours
We present the PSP and USP variants of the functions End, End.X and We present the PSP, USP and USD variants of the functions End, End.X
End.T. For each of these functions these variants can be enabled or and End.T. For each of these functions these variants can be enabled
disabled either individually or together. or disabled either individually or together.
4.21.1. PSP: Penultimate Segment Pop of the SRH 4.21.1. PSP: Penultimate Segment Pop of the SRH
After the instruction 'update the IPv6 DA with SRH[SL]' is executed, After the instruction 'update the IPv6 DA with SRH[SL]' is executed,
the following instructions must be added: the following instructions must be added:
1. IF updated SL = 0 & PSP is TRUE 1. IF updated SL = 0 & PSP is TRUE
2. pop the top SRH ;; Ref1 2. pop the top SRH ;; Ref1
Ref1: The received SRH had SL=1. When the last SID is written in the Ref1: The received SRH had SL=1. When the last SID is written in the
skipping to change at page 24, line 24 skipping to change at page 24, line 24
T.Encaps Transit behavior with encapsulation in an SRv6 policy T.Encaps Transit behavior with encapsulation in an SRv6 policy
T.Encaps.Red Transit behavior with reduced encaps in an SRv6 policy T.Encaps.Red Transit behavior with reduced encaps in an SRv6 policy
T.Encaps.L2 T.Encaps applied to received L2 frames T.Encaps.L2 T.Encaps applied to received L2 frames
T.Encaps.L2.Red T.Encaps.Red applied to received L2 frames T.Encaps.L2.Red T.Encaps.Red applied to received L2 frames
This list can be expanded in case any new functionality requires it. This list can be expanded in case any new functionality requires it.
5.1. T: Transit behavior 5.1. T: Transit behavior
As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1; As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1;
SL=2) and S2 is neither a local address nor a local SID of N then N SL=1) and S2 is neither a local address nor a local SID of N then N
forwards the packet without inspecting the SRH. forwards the packet without inspecting the SRH.
This means that N treats the following two packets with the same This means that N treats the following two packets with the same
performance: performance:
- (A, S2) - (A, S2)
- (A, S2)(S3, S2, S1; SL=2) - (A, S2)(S3, S2, S1; SL=1)
A transit node does not need to count by default the amount of A transit node does not need to count by default the amount of
transit traffic with an SRH extension header. This accounting might transit traffic with an SRH extension header. This accounting might
be enabled as an optional behavior. be enabled as an optional behavior.
A transit node MUST include the outer flow label in its ECMP load- A transit node MUST include the outer flow label in its ECMP load-
balancing hash [RFC6437]. balancing hash [RFC6437].
5.2. T.Insert: Transit with insertion of an SRv6 Policy 5.2. T.Insert: Transit with insertion of an SRv6 Policy
skipping to change at page 25, line 11 skipping to change at page 25, line 11
SID list <S1, S2, S3>. SID list <S1, S2, S3>.
The "T.Insert" transit insertion behavior is defined as follows: The "T.Insert" transit insertion behavior is defined as follows:
1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis 1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis
2. set the IPv6 DA = S1 2. set the IPv6 DA = S1
3. forward along the shortest path to S1 3. forward along the shortest path to S1
Ref1: The received IPv6 DA is placed as last SID of the inserted SRH. Ref1: The received IPv6 DA is placed as last SID of the inserted SRH.
Ref1bis: The SRH is inserted before any other IPv6 Routing Extension Ref1bis: The SRH is inserted
Header. [I-D.voyer-6man-extension-header-insertion] before any other IPv6
Routing Extension Header.
After the T.Insert behavior, P1 and P2 respectively look like: After the T.Insert behavior, P1 and P2 respectively look like:
- (A, S1) (B2, S3, S2, S1; SL=3) -(A, S1) (B2, S3, S2, S1; SL=3)
- (A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1) -(A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1)
5.3. T.Insert.Red: Transit with reduced insertion 5.3. T.Insert.Red: Transit with reduced insertion
The T.Insert.Red behavior is an optimization of the T.Insert The T.Insert.Red behavior is an optimization of the T.Insert
behavior. It is defined as follows: behavior. It is defined as follows:
1. insert the SRH (B2, S3, S2; SL=3) 1. insert the SRH (B2, S3, S2; SL=3)
2. set the IPv6 DA = S1 2. set the IPv6 DA = S1
3. forward along the shortest path to S1 3. forward along the shortest path to S1
skipping to change at page 27, line 22 skipping to change at page 27, line 22
and there is no need to use any flag, tag or TLV. and there is no need to use any flag, tag or TLV.
5.6. T.Encaps.L2: Transit with encapsulation of L2 frames 5.6. T.Encaps.L2: Transit with encapsulation of L2 frames
While T.Encaps encapsulates the received IP packet, T.Encaps.L2 While T.Encaps encapsulates the received IP packet, T.Encaps.L2
encapsulates the received L2 frame (i.e. the received ethernet header encapsulates the received L2 frame (i.e. the received ethernet header
and its optional VLAN header is in the payload of the outer packet). and its optional VLAN header is in the payload of the outer packet).
If the outer header is pushed without SRH, then the DA must be a SID If the outer header is pushed without SRH, then the DA must be a SID
of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header
must be 59 (IPv6 NoNextHeader). The received Ethernet frame follows must be 59 (IPv6 No Next Header [RFC8200]). The received Ethernet
the IPv6 header and its extension headers. frame follows the IPv6 header and its extension headers.
Else, if the outer header is pushed with an SRH, then the last SID of Else, if the outer header is pushed with an SRH, then the last SID of
the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and
the next-header of the SRH must be 59 (IPv6 NoNextHeader). The the next-header of the SRH must be 59 (IPv6 No Next Header
received Ethernet frame follows the IPv6 header and its extension [RFC8200]). The received Ethernet frame follows the IPv6 header and
headers. its extension headers.
The SRH MAY be omitted when the SRv6 Policy only contains one segment The SRH MAY be omitted when the SRv6 Policy only contains one segment
and there is no need to use any flag, tag or TLV. and there is no need to use any flag, tag or TLV.
5.7. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 5.7. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames
The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2 The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2
behavior. behavior.
T.Encaps.L2.Red will reduce the size of the SRH by one segment by T.Encaps.L2.Red will reduce the size of the SRH by one segment by
skipping to change at page 34, line 5 skipping to change at page 33, line 39
This registry is being defined to serve as a top-level registry for This registry is being defined to serve as a top-level registry for
keeping all other SRv6 sub-registries. keeping all other SRv6 sub-registries.
- A sub-registry "SRv6 Endpoint Behaviors" to be defined under top- - A sub-registry "SRv6 Endpoint Behaviors" to be defined under top-
level "Segment-routing with IPv6 dataplane (SRv6) Parameters" level "Segment-routing with IPv6 dataplane (SRv6) Parameters"
registry. This sub-registry maintains 16-bit identifiers for the registry. This sub-registry maintains 16-bit identifiers for the
SRv6 Endpoint behaviors. The range of the registry is 0-65535 SRv6 Endpoint behaviors. The range of the registry is 0-65535
(0x0000 - 0xFFFF) and has the following registration rules and (0x0000 - 0xFFFF) and has the following registration rules and
allocation policies: allocation policies:
+-------------+---------------+--------------------+----------------+ +-------------+---------------+---------------------------+---------+
| Range | Hex | Registration | Notes | | Range | Hex | Registration procedure | Notes |
| | | proceadure | | +-------------+---------------+---------------------------+---------+
+-------------+---------------+--------------------+----------------+ | 0 | 0x0000 | Reserved | Invalid |
| 0 | 0x0000 | Reserved | Invalid | | 1-32767 | 0x0001-0x7FFF | Specification Required | |
| 1-32767 | 0x0001-0x7FFF | IETF review | Draft | | 32768-49151 | 0x8000-0xBFFF | Reserved for experimental | |
| | | | Specifications | | | | use | |
| 32768-49151 | 0x8000-0xBFFF | Reserved for | | | 49152-65534 | 0xC000-0xFFFE | Reserved for private use | |
| | | experimental use | | | 65535 | 0xFFFF | Reserved | Opaque |
| 49152-65534 | 0xC000-0xFFFE | Reserved for | | +-------------+---------------+---------------------------+---------+
| | | private use | |
| 65535 | 0xFFFF | Reserved | Opaque |
+-------------+---------------+--------------------+----------------+
Table 3: SRv6 Endpoint Behaviors Registry Table 3: SRv6 Endpoint Behaviors Registry
The initial registrations for the "Draft Specifications" portion of The initial registrations for the "Specification Required" portion of
the sub-registry are as follows: the sub-registry are as follows:
+-------+--------+---------------------------+-----------+ +-------+--------+---------------------------+-----------+
| Value | Hex | Endpoint function | Reference | | Value | Hex | Endpoint function | Reference |
+-------+--------+---------------------------+-----------+ +-------+--------+---------------------------+-----------+
| 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] |
| 2 | 0x0002 | End with PSP | [This.ID] | | 2 | 0x0002 | End with PSP | [This.ID] |
| 3 | 0x0003 | End with USP | [This.ID] | | 3 | 0x0003 | End with USP | [This.ID] |
| 4 | 0x0004 | End with PSP&USP | [This.ID] | | 4 | 0x0004 | End with PSP&USP | [This.ID] |
| 5 | 0x0005 | End.X (no PSP, no USP) | [This.ID] | | 5 | 0x0005 | End.X (no PSP, no USP) | [This.ID] |
skipping to change at page 36, line 5 skipping to change at page 35, line 5
| 34 | 0x0022 | End.X with USP&USD | [This.ID] | | 34 | 0x0022 | End.X with USP&USD | [This.ID] |
| 35 | 0x0023 | End.X with PSP, USP & USD | [This.ID] | | 35 | 0x0023 | End.X with PSP, USP & USD | [This.ID] |
| 36 | 0x0024 | End.T with USD | [This.ID] | | 36 | 0x0024 | End.T with USD | [This.ID] |
| 37 | 0x0025 | End.T with PSP&USD | [This.ID] | | 37 | 0x0025 | End.T with PSP&USD | [This.ID] |
| 38 | 0x0026 | End.T with USP&USD | [This.ID] | | 38 | 0x0026 | End.T with USP&USD | [This.ID] |
| 39 | 0x0027 | End.T with PSP, USP & USD | [This.ID] | | 39 | 0x0027 | End.T with PSP, USP & USD | [This.ID] |
+-------+--------+---------------------------+-----------+ +-------+--------+---------------------------+-----------+
Table 4: IETF - SRv6 Endpoint Behaviors Table 4: IETF - SRv6 Endpoint Behaviors
The SRv6 Endpoint Behavior numbers are maintained by the working
group until the RFC is published. Note to the RFC Editor: Remove
this paragraph before publication.
10. Work in progress 10. Work in progress
We are working on a extension of this document to provide Yang We are working on a extension of this document to provide Yang
modelling for all the functionality described in this document. This modelling for all the functionality described in this document. This
work is ongoing in [I-D.raza-spring-srv6-yang]. work is ongoing in [I-D.raza-spring-srv6-yang].
11. Acknowledgements 11. Acknowledgements
The authors would like to acknowledge Stefano Previdi, Dave Barach, The authors would like to acknowledge Stefano Previdi, Dave Barach,
Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul
skipping to change at page 36, line 31 skipping to change at page 35, line 35
12. Contributors 12. Contributors
Daniel Bernier Daniel Bernier
Bell Canada Bell Canada
Canada Canada
Email: daniel.bernier@bell.ca Email: daniel.bernier@bell.ca
Dirk Steinberg Dirk Steinberg
Lapishills Consulting Limited Lapishills Consulting Limited
Germany Cyprus
Email: dirk@lapishills.com Email: dirk@lapishills.com
Robert Raszuk Robert Raszuk
Bloomberg LP Bloomberg LP
United States of America United States of America
Email: robert@raszuk.net Email: robert@raszuk.net
Bruno Decraene Bruno Decraene
skipping to change at page 39, line 15 skipping to change at page 38, line 20
Cisco Systems, Inc. Cisco Systems, Inc.
United States of America United States of America
Email: zali@cisco.com Email: zali@cisco.com
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
(SRH)", draft-ietf-6man-segment-routing-header-18 (work in Routing Header (SRH)", draft-ietf-6man-segment-routing-
progress), April 2019. header-21 (work in progress), June 2019.
[I-D.voyer-6man-extension-header-insertion]
daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes,
D., Previdi, S., and S. Matsushima, "Insertion of IPv6
Segment Routing Headers in a Controlled Domain", draft-
voyer-6man-extension-header-insertion-05 (work in
progress), January 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 40, line 30 skipping to change at page 39, line 43
[I-D.ietf-isis-l2bundles] [I-D.ietf-isis-l2bundles]
Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
E. Aries, "Advertising L2 Bundle Member Link Attributes in E. Aries, "Advertising L2 Bundle Member Link Attributes in
IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
May 2017. May 2017.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing- Policy Architecture", draft-ietf-spring-segment-routing-
policy-02 (work in progress), October 2018. policy-03 (work in progress), May 2019.
[I-D.raza-spring-srv6-yang] [I-D.raza-spring-srv6-yang]
Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I., Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I.,
Shah, H., daniel.voyer@bell.ca, d., Elmalky, H., Shah, H., daniel.voyer@bell.ca, d., Elmalky, H.,
Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data
Model for SRv6 Base and Static", draft-raza-spring- Model for SRv6 Base and Static", draft-raza-spring-
srv6-yang-02 (work in progress), October 2018. srv6-yang-03 (work in progress), May 2019.
[I-D.xuclad-spring-sr-service-programming] [I-D.xuclad-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-xuclad-spring-sr-service- Segment Routing", draft-xuclad-spring-sr-service-
programming-02 (work in progress), April 2019. programming-02 (work in progress), April 2019.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
skipping to change at page 41, line 33 skipping to change at page 41, line 4
Cisco Systems, Inc. Cisco Systems, Inc.
Belgium Belgium
Email: cf@cisco.com Email: cf@cisco.com
Pablo Camarillo Garvia (editor) Pablo Camarillo Garvia (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Spain Spain
Email: pcamaril@cisco.com Email: pcamaril@cisco.com
John Leddy John Leddy
Comcast Individual Contributor
United States of America United States of America
Email: john_leddy@cable.comcast.com Email: john@leddy.net
Daniel Voyer Daniel Voyer
Bell Canada Bell Canada
Canada Canada
Email: daniel.voyer@bell.ca Email: daniel.voyer@bell.ca
Satoru Matsushima Satoru Matsushima
SoftBank SoftBank
1-9-1,Higashi-Shimbashi,Minato-Ku 1-9-1,Higashi-Shimbashi,Minato-Ku
Tokyo 105-7322 Tokyo 105-7322
Japan Japan
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
 End of changes. 36 change blocks. 
75 lines changed or deleted 95 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/