< draft-li-spring-compressed-srv6-np-00.txt   draft-li-spring-compressed-srv6-np-01.txt >
SPRING Working Group Z. Li SPRING Working Group Z. Li
Internet-Draft C. Li Internet-Draft C. Li
Intended status: Standards Track S. Peng Intended status: Standards Track Huawei Technologies
Expires: January 23, 2020 Z. Wang Expires: July 26, 2020 C. Xie
B. Liu China Telecom
D. Voyer
Bell Canada
K. LEE
LG U+
H. Tian
F. Zhao
CAICT
J. Guichard
Futurewei Technologies
C. Li
China Telecom
S. Peng
Huawei Technologies Huawei Technologies
July 22, 2019 January 23, 2020
Compressed SRv6 Network Programming Compressed SRv6 Network Programming
draft-li-spring-compressed-srv6-np-00 draft-li-spring-compressed-srv6-np-01
Abstract Abstract
Segment Routing can be applied to the IPv6 data plane by leveraging a Segment Routing can be applied to the IPv6 data plane by leveraging a
new type of Routing Extension Header, called Segment Routing new type of Routing Extension Header, called Segment Routing Header
Header(SRH). However, the overhead introduced by SRH may be a (SRH). However, the overhead introduced by SRH may be a challenge
challenge for the current hardware capability, which would have much for existing hardware, which may influence on the forwarding
effect on the forwarding performance and the payload efficiency. performance and the payload efficiency.
This document defines a compressed SRv6 network programming mechanism This document defines a compressed SRv6 network programming mechanism
in order to reduce the overhead of SRv6 by introducing the Compressed in order to reduce the overhead of SRv6 by introducing the Compressed
Segment Identifier(C-SID) and the Compressed SRH(C-SRH). The C-SRH Segment Identifier (C-SID) and the Compressed SRH (C-SRH). The C-SRH
can be a new Routing Header or an enhancement of SRH, which is can be a new Routing Header or an enhancement of SRH.
compatible with SRH well.
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 January 23, 2020. This Internet-Draft will expire on July 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Compressed SID(C-SID) . . . . . . . . . . . . . . . . . . . . 3 3. Compressed SID (C-SID) . . . . . . . . . . . . . . . . . . . 4
4. Compressed Segment Routing Header(C-SRH) . . . . . . . . . . 4 4. Compressed Segment Routing Header (C-SRH) . . . . . . . . . . 5
5. C-SRH Processing . . . . . . . . . . . . . . . . . . . . . . 7 5. C-SRH Processing . . . . . . . . . . . . . . . . . . . . . . 10
6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Control Plane Consideration . . . . . . . . . . . . . . . . . 13
6.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 9 7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Compressed SRv6 Forwarding Example . . . . . . . . . . . 9 7.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 15
7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Compressed SRv6 Forwarding Example . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Inter-domain Routing Using C-SRH . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 13 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Segment routing (SR) [RFC8402] is a source routing paradigm that Segment routing (SR) [RFC8402] is a source routing paradigm that
explicitly indicates the forwarding path for packets at the ingress explicitly indicates the forwarding path for packets at the ingress
node by inserting an ordered list of instructions, called segments. node by inserting an ordered list of instructions, called segments.
When segment routing is deployed on IPv6 data plane, it is called When segment routing is deployed on the IPv6 data plane, it is called
SRv6 [I-D.ietf-6man-segment-routing-header].An SRv6 Segment ID(SID) SRv6 [I-D.ietf-6man-segment-routing-header].An SRv6 Segment ID (SID)
is a 128-bit value, and it can be represented as LOC:FUNCT where LOC is a 128-bit value, and it can be represented as LOC:FUNCT where LOC
is the L most significant bits and FUNCT is the 128-L least is the L most significant bits and FUNCT is the 128-L least
significant bits [I-D.ietf-spring-srv6-network-programming]. L is significant bits [I-D.ietf-spring-srv6-network-programming]. L is
called the locator length and is flexible. Each operator is free to called the locator length and is flexible. Each network operator is
use the locator length it chooses. The LOC part of the SID is free to use the locator length it chooses. The LOC part of the SID
routable and leads to the node which instantiates that SID. is routable and leads to the node which instantiates that SID.
For supporting SR, a new routing header called Segment Routing Header For support of SR, a new routing header called Segment Routing Header
(SRH), which contains a list of SIDs and other information such as (SRH), which contains a list of SIDs and other information, has been
Segments Left, has been defined in defined in [I-D.ietf-6man-segment-routing-header]. In use cases like
[I-D.ietf-6man-segment-routing-header]. In use cases like Traffic Traffic Engineering, an ordered SID List with multiple SIDs is
Engineering, an ordered SID List with multiple SIDs is inserted into inserted into the SRH to steer packets along an explicit path.
the SRH to steer packets in an explicit path.
However, the overhead of SIDs(16 bytes per SID) may be a challenge However, the overhead of SIDs (16 bytes per SID) may be a challenge
for the current hardware processing capability. The large size of for existing hardware processing, as the size of the SRH may affect
SRH will have much effect on the forwarding performance. Also, when the forwarding performance. When the packet is small, the payload
the packet is small, the payload efficiency is not ideal due to the efficiency is not ideal due to the large overhead of the SRH. When
large overhead of SRH. When the packet is large, the large overhead the packet is large, the overhead of the SRH may cause the packet to
of SRH may also cause the packet to be dropped due to PMTU [RFC8200]. be dropped due to PMTU [RFC8200].
This document defines a compressed SRv6 network programming mechanism This document defines a compressed SRv6 network programming mechanism
to order to reduce the overhead of SRv6 by introducing the Compressed in order to reduce the overhead of SRv6 by introducing the Compressed
Segment Identifier(C-SID) and the Compressed SRH(C-SRH). The C-SRH Segment Identifier (C-SID) and the Compressed SRH (C-SRH). The C-SRH
can be a new Routing Header or an enhancement of SRH, which is can be a new Routing Header or an enhancement of SRH, in either case,
compatible with SRH well. compatibility with the existing SRH is maintained.
2. Terminology 2. Terminology
This document makes use of the terms defined in This document makes use of the terms defined in
[I-D.ietf-6man-segment-routing-header], [RFC8402] and [RFC8200]. The [I-D.ietf-6man-segment-routing-header], [RFC8402] and [RFC8200], and
reader is assumed to be familiar with the terminology defined in the reader is assumed to be familiar with that terminology. This
them. This document introduce the following terms: document introduces the following new terms:
C-SRH: Compressed Segment Routing Header C-SRH: Compressed Segment Routing Header
C-SID: Compressed Segment Identifier C-SID: Compressed Segment Identifier
C-Tag: Compressed Tag C-Tag: Compressed Tag
2.1. Requirements Language 2.1. 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
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Compressed SID(C-SID) 3. Compressed SID (C-SID)
This document defines a Compressed SID(C-SID) to carry the last N This document defines a Compressed SID (C-SID) to carry the last 16 -
bytes of the original SRv6 SID, which is the different part of the N bytes of the original SRv6 SID, where N is the length of the common
SID comparing with other SIDs in the SID List. prefix among SIDs in the SID list. N is calculated by comparing the
difference of each SID with other SIDs on the SID list.
N is the length of the common prefix among SIDs in the SID list. The The common prefix part contains the common part of all Locators in
common prefix part contains the common part of Locators in the SID the SID list, while the C-SID contains the different part, if any, of
list, while the C-SID contains the different part of Locator and all Locators and the Function ID of an SRv6 SID. Generally, in an
Function ID part of an SRv6 SID. SRv6 domain, the common prefix can be the SRv6 SID block as per
[I-D.ietf-spring-srv6-network-programming], and the C-SID consists of
the Node ID and Function ID.
The IPv6 DA contains a 128-bits(16 Bytes) SRv6 SID, and it can be The IPv6 DA contains a 128-bits (16 Bytes) SRv6 SID, and it can be
separated as two parts: the common prefix part among all SIDs, and separated into two parts: the common prefix among all SIDs, and the
the different part of a specific SID called C-SID that includes the current C-SID on the SID list.
different part of the locator and the Function ID.
0 N 16 bytes 0 N 16 bytes
+--------------------------------------------------------------+ +--------------------------------------------------------------+
| Common Prefix | C-SID | | Common Prefix | C-SID |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
|<----------------- Locator ------------------->|<-FunctionID->| |<----------------- Locator ------------------->|<-FunctionID->|
|<--->| |<--->|
| |
Different part of Locator Different part of Locator
Figure 1. C-SID in IPv6 DA Figure 1. C-SID in IPv6 DA
In this way, the common prefix is carried by the IPv6 DA only, and In this way, the common prefix is carried by the IPv6 DA only, and
the SIDs in SID list will not carry the prefix part, but only the the SIDs in the SID list will not carry the common prefix, but only
different part, the C-SID. the last 16 - N bytes of the original SRv6 SID.
Therefore, this document does not define any new types of the SRv6 Therefore, this document does not define any new SRv6 segment types.
Segment.
4. Compressed Segment Routing Header(C-SRH) Editor's Note: C-SID can be a fixed length value, such as 32 bits, if
the WG can reach a consensus on it, and actually authors suggest this
solution.
The C-SID is not needed to be the last N bits/Bytes of the SRv6 SID,
it can be at any location in the SRv6 SID. In the best case, it
follows the Common Prefix.
If the the length of Common prefix and C-SID is less than 128 bits,
than padding is required. With the padding, C-SID does not need to
be at the last part of SID, which will low down the compablities
requirement of hardware.
In this case, operators can allocate a appropriate length common
prefix for fitting their networks, and the fixed length of C-SID will
be good for the hardware to process.
For example, the Common Prefix is A::/48, C-SID is a 32 bits value,
and padding can be 48 bits zero, then only the 80 bits(Common prefix
+ C-SID) are used for routing, and only the C-SIDs should be carried
in SRH and updated to DA, which is good for ASIC hardware.
In the same time, this format of SID can support the explicit
match(Exact Match), which has better performance than LPM(Longes
Prefix Match). But vendors can implemente LPM for C-SID, it is up to
the vendor.
0 Variable Length 32 bits 128 bits
+--------------------------------------------------------------+
| Common Prefix | C-SID | Padding |
+--------------------------------------------------------------+
|<-------- Locator ---------------->|<-FuctID->|<---Padding--->|
|<--->|
|
Different part of Locator
Figure 1. 32 bits C-SID in IPv6 DA
The authors would like to have the comments from the working group,
to see which option is the best, so welcome to send your comments.
4. Compressed Segment Routing Header (C-SRH)
In order to carry the C-SID, this document defines the Compressed In order to carry the C-SID, this document defines the Compressed
Segment Routing Header (C-SRH). Segment Routing Header (C-SRH).
The C-SRH can be a new Routing Header which need to introduce a new The C-SRH can be a new Routing Header (with new Routing Type (TBD))
Routing type or just an enhancement of SRH (Note: the latter is or an enhancement of the SRH (Note: the latter is preferred in this
preferred in the document). document).
The C-SRH provides a more efficient encoding mechanism for SRv6, and The C-SRH provides a more efficient encoding mechanism for SRv6, and
it can be compatible with the SRv6 very well. is compatible with the existing SRv6 architecture.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left| | Next Header | Hdr Ext Len | Routing Type | Segments Left|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry |E| Flag | C-Tag | Tag | | Last Entry |E| Flag | C-Tag | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[0](16 - C-Tag bytes) | | Segment List[0](16 or 16 - C-Tag bytes) |
. ... . . ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[1](16 - C-Tag bytes) | | Segment List[1](16 - C-Tag bytes) |
. ... . . ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
. ... . . ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[n](16 - C-Tag bytes) | | Segment List[n](16 - C-Tag bytes) |
. ... . . ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Padding to align with 64 bits Boundary ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
// Optional Type Length Value objects (variable) // // Optional Type Length Value objects (variable) //
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Compressed Segment Routing Header Figure 2. Compressed Segment Routing Header
where: where:
o Next Header: Defined in [RFC8200] o Next Header: Defined in [RFC8200]
o Hdr Ext Len: Defined in [RFC8200] o Hdr Ext Len: Defined in [RFC8200]
o Routing Type: 4 when C-SRH is an enhancement of SRH, or other type o Routing Type: 4 when C-SRH is an enhancement of SRH, or new type
when C-SRH is a new Routing Header. (TBD) when C-SRH is a new Routing Header.
o Segments Left: Defined in [RFC8200] o Segments Left: Defined in [RFC8200]
o Last Entry: contains the index (zero based), in the Segment List, o Last Entry: contains the index (zero based), in the Segment List,
of the last element of the Segment List. of the last element of the Segment List.
o Flags: o Flags:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|U U U U U U U| |E|U U U U U U U|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
U: Unused and for future use. MUST be 0 on transmission and U: Unused and for future use. MUST be 0 on transmission and
ignored on receipt. ignored on receipt.
E: Exclude flag, set when the last SID is excluded in compression. E: Exclude flag, set when the last SID is excluded in compression.
1: the last SID is excluded in compression, and it is 16 1: the last SID is excluded in compression, and it is a 16
bytes(128 bits) value bytes (128 bits) value
0: the last is included in compression, and it is a 0: the last SID is included in compression, and it is a
16 - C-Tag bytes value 16 - C-Tag bytes value
o C-Tag: 4-bit unsigned integer to indicate the length of the common o C-Tag: 4-bit unsigned integer to indicate the length of the common
prefix. Therefore, the length of the C-SID in C-SRH is 16 - C-Tag prefix. Therefore, the length of the C-SID in C-SRH is 16 - C-Tag
bytes except the last segment if and only if the E-flag is set. bytes except the last segment if and only if the E-flag is set.
When the C-Tag is 0, means the length of C-SIDs in C-SRH is 16 When the C-Tag is 0, the length of C-SIDs in C-SRH is 16 bytes,
bytes, which is compatible with the SRH which is compatible with the existing SRH
[I-D.ietf-6man-segment-routing-header]. [I-D.ietf-6man-segment-routing-header].
o Tag: 12 bits value to tag a packet as part of a class or group of o Tag: 12 bits value to tag a packet as part of a class or group of
packets, e.g., packets sharing the same set of properties as per packets, e.g., packets sharing the same set of properties as per
[I-D.ietf-6man-segment-routing-header]. [I-D.ietf-6man-segment-routing-header].
o Segment List[0]: 16 bytes (128 bits ) IPv6 address when E-flag is o Segment List[0]: 16 bytes (128 bits ) IPv6 address when E-flag is
set, and last 16 - C-Tag bytes of SID when E-flag is unset. set, and last 16 - C-Tag bytes of SID when E-flag is unset.
o Segment List[n]: a compressed SRv6 SID, which is the last 16 - o Segment List[n]: a compressed SRv6 SID, which is the last 16 -
skipping to change at page 7, line 7 skipping to change at page 8, line 7
In some use cases, the last SID may be a normal SID, which has a In some use cases, the last SID may be a normal SID, which has a
different prefix against all other SIDs, so it can be excluded in different prefix against all other SIDs, so it can be excluded in
C-SID generation for better compression. C-SID generation for better compression.
The E-flag indicates whether the last SID is excluded in compression. The E-flag indicates whether the last SID is excluded in compression.
When E-flag is set, Segment List[0] will carry the original SID, When E-flag is set, Segment List[0] will carry the original SID,
otherwise, it carries the compressed SID, i.e. the last 16 - C-Tag otherwise, it carries the compressed SID, i.e. the last 16 - C-Tag
bytes of the original Segment List[0]. bytes of the original Segment List[0].
Padding is needed after the SID List[Last entry] to align with 64
bits.
Editor's Note: The authors had consided that there are some
mechanisms to indicate compression, authors would like to have the
comments from the working group, to see which option is the best, so
welcome to send your comments.
1. Option 1: Compression Tag: C-tag in SRH
* Compression tag indicates the length of Common prefix
explicitly.
* Indicate the length of C-SID as well, if the length of C-SID
is a well-known length value.
* No need to modify the control plane to distribute new type of
SIDs.
* SRH is modified, some bits are needed.
* A SID can be used for normal SRv6 routing or Compression SRv6
routing.
* New SID space for compression is optional.
2. Option 2: Compression Flag: C-flag in SRH
* C-flag indicates compression, and the length of common prefix
is learned from the control plane or configuration.
* Indicate the length of C-SID as well, if the length of C-SID
is a well-known length value.
* Need to distribute the length of Common prefix or configure it
in the SRv6 domain.
* SRH is modified, a bit in flag for indicating compression is
needed.
* A SID can be used for normal SRv6 routing or Compression SRv6
routing.
* New SID space for compression is optional.
3. Option 3: Compression Flavor/SID/Locator/SID Space: C Flavor/C
Type in Control plane
* New compression type of SIDs or SIDs with C flavor, they
should be distributed via control plane, such as IGP.
* The format of SID should be distributed via control plane,
such as the length of common prefix.
* SRH is not modified.
* C-SID is used for compression SRv6 routing only.
* New SID space for compression is required.
The format of C-SRH of Option 2 and 3 are shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry |C| Flag | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[0](N bytes) |
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[1] (N bytes) |
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[n](N bytes) |
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Padding to align with 64 bits Boundary ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Compressed Segment Routing Header with C-flag
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flag | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[0](N bytes) |
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[1](N bytes) |
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[N](N bytes) |
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Padding to align with 64 bits Boundary ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. C-SRH without changing Common header of SRH
5. C-SRH Processing 5. C-SRH Processing
The compressed SID List can be generated by the ingress node itself The compressed SID List can be generated by the ingress node by
by comparing the SIDs to get the C-Tag value according to the length comparing the SIDs to get the C-Tag value according to the length of
of the prefix, and derive the compressed SID list. The compressed the common prefix. The compressed SID List can also be generated by
SID List can also be generated by the Controller and send to the a Controller and be sent to the ingress node, and the necessary
ingress as well which need to introduce the extra protocol extension. protocol extensions for this are outside the scope of this document.
(Note: The former is preferred in the document) (Note: The former is preferred in this document)
When the ingress node applies SRv6 policy to packets, a C-SRH can be When the ingress node applies SRv6 policy to packets, a C-SRH can be
encapsulated in a new IPv6 header(Encapsulation Mode). The first SID encapsulated in a new IPv6 header (Encapsulation Mode). The first
is carried in the DA, and the different parts of all SIDs, as known SID is carried along with the common prefix in the DA, and the
as C-SIDs, are carried in the SID List of C-SRH. The last SID is remaining C-SIDs are carried in the SID List of the C-SRH. The last
inserted according to the E-flag. SID is inserted according to the E-flag.
When an SRv6 endpoint node receives the packets, the node will follow When an SRv6 endpoint node receives the packet, the node will follow
the same processing procedure of SRH, that is, to inspect whether the the same processing procedure as with an SRH, that is, to inspect
DA is a local SID or not, if yes, then process the SID according to whether the DA is a local SID or not, if yes, then process the SID
its function. Otherwise, it will perform regular IPv6 forwarding. according to its function. Otherwise, it will perform regular IPv6
forwarding.
When DA is a local SID, then the node will process the C-SRH and the When the DA is a local SID, then the node will process the C-SRH and
C-SIDs. the C-SIDs, and the current C-SID on the segment-list will replace
the last 16 - C-Tag bytes of the IPv6 DA.
In C-SID processing, the C-SID will be updated to the IPv6 DA to Regarding the last SID, if the E-flag is set, the entire 128 bits of
replace the last 16 - C-Tag bytes. Regarding the last SID, if the Segment List[0] is updated to IPv6 DA. Otherwise, the C-SID will be
E-flag is set, the entire 128 bit of Segment List[0] is updated to updated to replace the last 16 - C-Tag bytes of IPv6 DA. After
IPv6 DA. Otherwise, the C-SID will be updated to replace the last 16 updating the IPv6 DA, the packet will be forwarded accordingly.
- C-Tag bytes of IPv6 DA. After updating the IPv6 DA, the packet
will be forwarded accordingly.
The pseudo code of C-SRH processing is shown below. The pseudo code of C-SRH processing is shown below.
Editor's Note: The pseudo code will be updated when the options of
Compression SRv6 NP are converged.
01. When a C-SRH is processed { 01. When a C-SRH is processed {
02. If Segments Left is equal to zero { 02. If Segments Left is equal to zero {
03. Proceed to process the next header in the packet, 03. Proceed to process the next header in the packet,
whose type is identified by the Next Header field in whose type is identified by the Next Header field in
the Routing header. the Routing header.
04. } 04. }
05. Else { 05. Else {
06. If local configuration requires TLV processing { 06. If local configuration requires TLV processing {
07. Perform TLV processing 07. Perform TLV processing
08. } 08 //If E-flag is unset:
09. If E-flag is set: 09. // TLV begins at SID length + Padding Length
10. max_last_entry = (Hdr Ext Len - 8 - C-Tag)/(16 - C-Tag) 10. // SID Length = Last Entry * (16 - C-Tag)
11. Else: 11. // Padding Length = 8 - Last Entry * (16 - C-Tag)%8
12. max_last_entry = (Hdr Ext Len - 8)/(16 - C-Tag) 12. //Else:
13. If ((Last Entry > max_last_entry) or // TLV begins at SID length + Padding Length
14. (Segments Left is greater than (Last Entry+1)) { 13. // SID Length = Last Entry * (16 - C-Tag) + C-Tag
14. If (Segments Left is greater than (Last Entry+1)) {
15. Send an ICMP Parameter Problem, Code 0, message to 15. Send an ICMP Parameter Problem, Code 0, message to
the Source Address, pointing to the Segments Left the Source Address, pointing to the Segments Left
field, and discard the packet. field, and discard the packet.
16. } 16. }
17. Else { 17. Else {
18. Decrement Segments Left by 1. 18. Decrement Segments Left by 1.
19. if Segments Left > 0 or Segments Left = 0 and E-flag = 0: 19. if Segments Left > 0 or Segments Left = 0 and E-flag = 0:
20. // Update the C-SID to the DA 20. // Update the C-SID to the DA
21. Copy Segment List[Segments Left] from the SRH to 21. Copy Segment List[Segments Left] from the SRH to
replace the last 16 - C-Tag bytes of replace the last 16 - C-Tag bytes of
skipping to change at page 9, line 5 skipping to change at page 13, line 5
27. } 27. }
28. Else { 28. Else {
29. Decrement the Hop Limit by 1 29. Decrement the Hop Limit by 1
30. Resubmit the packet to the IPv6 module for 30. Resubmit the packet to the IPv6 module for
transmission to the new destination. transmission to the new destination.
31. } 31. }
32. } 32. }
33. } 33. }
34. } 34. }
6. Illustration 6. Control Plane Consideration
Editor's note: Control Plane consideration will be described in
separate drafts in the future. Note that, some extensions may be not
needed in some Compression options.
For indicating compression, the node should advertise the
capabilities of SRv6 compression via control plane. A C-flag should
be added in:
o SRv6 Capabilities sub-TLV in IS-IS
[I-D.ietf-lsr-isis-srv6-extensions]
o SRv6-Capabilities TLV in OSPF
[I-D.li-ospf-ospfv3-srv6-extensions],
o OPEN Object/PATH-SETUP-TYPE-CAPABILITIES TLV/SRv6 Capabilities
sub-TLV in PCEP [I-D.ietf-pce-segment-routing-ipv6]
For distributing the C-SID in control plane, the C-flag should be
added to the following TLV or sub-TLV in IGP/BGP/BGP-LS and PCEP.
o IS-IS [I-D.ietf-lsr-isis-srv6-extensions]:
* SRv6 Locator TLV, when C-flag is set, the Locator Block length
is less than 96 if the C-SID is a 32 bits value.
* SRv6 END.X/ LAN END.X sub-TLV
o OSPF [I-D.li-ospf-ospfv3-srv6-extensions]
* SRv6 Locator TLV, when C-flag is set, the Locator Block length
is less than 96 if the C-SID is a 32 bits value.
* SRv6 END.X/ LAN END.X sub-TLV , when C-flag is set, the Locator
Block length is less than 96 if the C-SID is a 32 bits value.
o BGP [I-D.ietf-bess-srv6-services]
* SRv6 SID Information sub-TLV, when C-flag is set, the Locator
Block length is less than 96 if the C-SID is a 32 bits value.
o BGP-LS [I-D.ietf-idr-bgpls-srv6-ext]
* SRv6 Link Attributes: SRv6 END.X SID TLV/LAN END.X SID TLV,
when C-flag is set, the Locator Block length is less than 96 if
the C-SID is a 32 bits value.
* SRv6 Prefix Attributes: SRv6 Locator TLV, when C-flag is set,
the Locator Block length is less than 96 if the C-SID is a 32
bits value.
* SRv6 SID Attributes: SRv6 Endpoint Function TLV, when C-flag is
set, the Locator Block length is less than 96 if the C-SID is a
32 bits value.
* SRv6 SID Attributes: SRv6 BGP Peer Node SID TLV, when C-flag is
set, the Locator Block length is less than 96 if the C-SID is a
32 bits value.
For distributing SRv6 Policy with compression SIDs, a C-flag should
be added in BGP and PCEP.
o BGP SR Policy [I-D.ietf-idr-segment-routing-te-policy]
* SRv6 Segment List sub-TLV, when C-flag is set, the Locator
Block length is less than 96 if the C-SID is a 32 bits value.
Candidate path and SR Policy level's extensions will be
described in the future revision.
* Segment sub-TLV, when C-flag is set, the Locator Block length
is less than 96 if the C-SID is a 32 bits value. The entire
SID is still carried in the SR Policy, while the C-flag will
indicate this is a compression SID with C-SID.
+ Type 2: SRv6 SID
+ Type 9: IPv6 Node addr with opt SRv6 SID
+ Type 10: IPv6 addr+intf ID for Local and remote pair for
SRv6 with opt SID
o PCEP
* PATH-SETUP-TYPE TLV [RFC8408]: When PST is 2, the the C-flag
indicates the SID list of the Path should be Compression SID.
* SRv6 ERO Subobject [I-D.ietf-pce-segment-routing-ipv6]
* SRv6 RRO Subobject [I-D.ietf-pce-segment-routing-ipv6]
7. Illustration
This section describes a simple example to illustrate the usage of This section describes a simple example to illustrate the usage of
C-SID. Similar to [I-D.filsfils-spring-srv6-net-pgm-illustration], C-SID. Similar to [I-D.filsfils-spring-srv6-net-pgm-illustration],
in order to ease the reading of the example, we introduce a simple in order to ease the reading of the example, we introduce a simple
reference diagram and simplified SID allocations. reference diagram and simplified SID allocations.
6.1. Reference Diagram Editor's note: the following part will be updated accordingly when
the compression option is converged in WG.
7.1. Reference Diagram
Nodes 1 - 8 are SRv6 enabled nodes within the network domain. Nodes 1 - 8 are SRv6 enabled nodes within the network domain.
Nodes CE1, CE2, and CE3 are outside the domain. Nodes CE1, CE2, and CE3 are outside the domain.
CE1 and CE2 are tenants of VPN 100. CE1 and CE2 are tenants of VPN 10.
Nodes 1 and 8 act as PE respectively to nodes CE1 and CE3. Nodes 1 and 8 act as PE respectively to nodes CE1 and CE3.
All the links within the domain have the same IGP metric. All the links within the domain have the same IGP metric.
The IGP metric shortest-path from 1 to 8 is 1-2-7-8, while the The IGP metric shortest-path from 1 to 8 is 1-2-7-8, while the
latency-metric shortest-path from 1 to 8 is 1-2-3-4-5-6-7-8. latency-metric shortest-path from 1 to 8 is 1-2-3-4-5-6-7-8.
CE2 CE2
\ \
4------5 4------5
| | | |
+-----3------6 +-----3------6
| | / | | | / |
| | / | | | / |
| |/ | | |/ |
Tenant100 CE1---1-----2------7---8---CE3 Tenant100 with Tenant10 CE1---1-----2------7---8---CE3 Tenant10 with
IPv4 20/8 IPv4 20/8
Figure 3: Reference topology Figure 3: Reference topology
6.2. Compressed SRv6 Forwarding Example 7.2. Compressed SRv6 Forwarding Example
This section describes a simple example to show how efficient C-SRH This section describes a simple example to show how efficiently C-SRH
can reduce the overhead of SRv6. can reduce the overhead of SRv6.
In order to ease the reading of the example, it is better to In order to ease the reading of the example, it is better to
introduce a simplified SID allocations. We assume: introduce a simplified SID allocation schema. We assume:
o B::/112 is dedicated to the internal SRv6 SID space, which is the o B::/112 is dedicated to the internal SRv6 SID space, which is the
common prefix. Therefore the C-SID is a 16-bits value. common prefix. Therefore, the C-SID is a 16-bit value.
o A locator expressed in 120 bits and a function expressed in 8 o A locator expressed in 120 bits and a function expressed in 8
bits. bits.
o Node k has B::k/120 for its local SID space. Its SIDs will be o Node k has B::0k/120 for its local SID space. Its SIDs will be
explicitly allocated from that block. explicitly allocated from that block.
o Node k advertises B::k/120 in its IGP. o Node k advertises B::0k/120 in its IGP.
o Function ::1 (function 1, for short) represents the End function o Function 01 represents the End function with PSP support.
with PSP support.
o B::k::1 represents the End function with PSP support allocated by o B::0k01 represents the End function with PSP support allocated by
node K, such as B::6::1 represents the End function with PSP node K, such as B::0601 represents the End function with PSP
support allocated by node 6. support allocated by node 6.
o B::8::D100 is an END.DT4 SID initiated by node 8, which is o B::0810 is an END.DT4 SID initiated by node 8, which is associated
associated with the VRF100. with the VRF10.
In SRH based SRv6, the PE 1 encapsulates the packets (CE1, CE3) from In SRH based SRv6, the PE 1 encapsulates the packets from CE1 to CE3
CE1 to CE3 in an outer IPv6 header with DA = B::3::1 and SRH in an outer IPv6 header with DA = B::0201 and SRH (B::0810, B::0701,
(B::8::D100, B::7::1, B::6::1, B::5::1, B::4::1, B::3::1, B::2::1; B::0601, B::0501, B::0401, B::0301, B::0201; SL=6; NH=4).
SL=6; NH=4).
<B::2::1, B::3::1, B::4::1, B::5::1, B::6::1, B::7::1, B::8::D100> <B::0201, B::0301, B::0401, B::0501, B::0601, B::0701, B::0810>
follows the latency-metric shortest-path. The total length of SRH is follows the latency-metric shortest-path. The total length of SRH is
8+16*7=120 bytes. 8+16*7=120 bytes.
In Compressed SRv6, PE 1 encapsulates (CE1, CE3) in an outer IPv6 In Compressed SRv6, PE 1 encapsulates the packets from CE1 to CE3 in
header with DA = B::2::1 and C-SRH (B::8::D100, 7::1, 6::1, 5::1, an outer IPv6 header with DA = B::0201 and C-SRH (0810, 0701, 0601,
4::1, 3::1, 2::1, SL=6; NH=4) with E-flag set. The C-Tag is 14, 0501, 0401, 0301, 0201, SL=6; NH=4) with E-flag unset. The C-Tag is
since the length of same prefix is 112 bits. Therefore, the total 14, since the length of the common prefix is 112 bits. Therefore,
length of C-SRH is 8 + (16-14)*6 + 16 = 36 bytes, then 84 bytes are the total length of C-SRH is 8 + (16-14)*7 = 22 bytes, reducing the
reduced meaning 70% size of the SRv6 overhead or 87.5% of SIDs encapsulation overhead by 98 bytes (81.7% less overhead than SRH) or
(except the last SID) overhead are reduced. 87.5% reduction in SIDs overhead.
The packet leaves node 1 to node 2 according to the FIB associated The packet leaves node 1 to node 2 according to the FIB associated
with the IPv6 DA B::2::1. The packet leaves node 1 can be present as with the IPv6 DA B::0201. The packet can be presented as:
(A::1, B::2::1) (A::1, B::0201)
(B::8::D100, 7::1, 6::1, 5::1, 4::1, 3::1, 2::1, SL=6; NH=4) (0810, 0701, 0601, 0501, 0401, 0301, 0201, SL=6; NH=4)
(X, Y) (CE1, CE3)
When 2 receives the packet, 2 matches B::2::1 in its "My SID Table" When 2 receives the packet, 2 matches B::0201 in its "My SID Table"
and executes the END function behavior to update the IPv6 DA. Since and executes the END function behavior to update the IPv6 DA. Since
the updated SL is greater than 0, and the C-Tag is 14, then it copies the updated SL is greater than 0, and the C-Tag is 14, then it copies
the C-SID that is a 2 bytes value to replace the last 2 bytes of IPv6 the C-SID that is a 2 bytes value to replace the last 2 bytes of the
DA, and then forward the packet according the new IPv6 DA B::3::1. IPv6 DA, and then forwards the packet according to the new IPv6 DA
The packet leaves node 2 can be present as B::0301. The packet can be presented as:
(A::1, B::3::1)
(B::8::D100, 7::1, 6::1, 5::1, 4::1, 3::1, 2::1, SL=5; NH=4)
(X, Y)
Similar to node 2, the node 3, 4, 5, and 6 performs the END function (A::1, B::0301)
(0810, 0701, 0601, 0501, 0401, 0301, 0201, SL=5; NH=4)
(CE1, CE3)
Like node 2, the nodes 3, 4, 5, and 6 perform the END function
behavior to update the IPv6 DA with the corresponding C-SID and then behavior to update the IPv6 DA with the corresponding C-SID and then
forward the packet by looking up FIB accordingly. Therefore, the forward the packet by looking up the IPv6 DA in their FIB
packet leaves node 6 can be present as accordingly. Therefore, the packet leaving node 6 can be presented
as:
(A::1, B::7::1) (A::1, B::0701)
(B::8::D100, 7::1, 6::1, 5::1, 4::1, 3::1, 2::1, SL=1; NH=4) (0810, 0701, 0601, 0501, 0401, 0301, 0201, SL=1; NH=4)
(X, Y) (CE1, CE3)
When 7 receives the packet, 7 matches B::7::1 in its "My SID Table" When 7 receives the packet, 7 matches B::0701 in its "My SID Table"
and executes the END function behavior to update the IPv6 DA. Since and executes the END function behavior to update the IPv6 DA. Since
the updated SL is 0 and E-flag is set, then the 128-bits Segment the updated SL is 0 and E-flag is unset, then it copies the C-SID
List[0] is copied to the IPv6 DA. Also, the C-SRH is popped since that is a 2 bytes value to replace the last 2 bytes of the IPv6 DA.
the B::7::1 is an END SID with PSP flavor. Node 7 then performs a Also, the C-SRH is popped since the B::0701 is an END SID with PSP
lookup on the updated IPv6 DA B::8::D100 to forward the packet along flavor. Node 7 then performs a lookup on the updated IPv6 DA B::0810
the shortest path to node 8. The packet leaves node 8 can be present to forward the packet along the shortest path to node 8. The packet
as can be presented as:
(A::1, B::8::D100) (A::1, B::0810)
(X, Y) (CE1, CE3)
When 8 receives the packet, 8 matches B::8::D100 in its "My SID When 8 receives the packet, 8 matches B::0810 in its "My SID Table"
Table" and executes the END.DT4 function behavior to sends the IP and executes the END.DT4 function behavior to sends the IP packet
packet (CE1, CE3) to its VPN destination. (CE1, CE3) to its VPN destination.
This example illustrates the procedure of C-SRH based SRv6 This example illustrates the procedure of C-SRH based SRv6
forwarding, it shows that the longer prefix can reduce more overhead forwarding, and shows that the longer the common prefix, the more the
of SRv6. More benefits are described in the section 7. SRv6 overhead can be reduced. More benefits are described in section
7.
7. Benefits 8. Inter-domain Routing Using C-SRH
1. Seamless integration with SRv6 Network Programming Considering privacy and security of SRv6 domain, when SRv6 is used
for inter-domain routing, the detailed SIDs will not be leaked
between domains, and the Binding SID [RFC8402] SHOULD be used. The
typical inter-domain using SRv6 is illustrated in Figure 4.
o No new type(Functions, such as END) of SRv6 SIDs is defined. When receiving the packet from CE1 to CE2, the Ingress node of SRv6
A C-SID is a sub-set of an SRv6 SID. domain A can generate an SRv6 packet with SID List <BSID1, BSID2,
VPN1>.
o Neither redefines the IPv6 address space nor requires any BSID1 is bound to an SR Policy, which contains a list of SID list in
specific IPv6 space. SRv6 Domain B, for example [B1::1, B2::1, B3::1, B4::1, B5::1].
2. Supporting Full Set Functionalities of SRv6 Similarly, BSID2 is bound to an SR Policy in SRv6 Domian C, for
example [C1::1, C2::1, C3::1, C4::1, C5::1].
o Full set functionalities of SRv6(BE,Loose TE and strict TE,etc.) VPN1 SID can be an END.DT4 SID associated with CE2.
are supported without any extra routes advertisements.
o Function ID information is maintained. In this way, the SIDs should be inserted at the ingress node are
reduced from 11 to 3.
3. Control-Plane friendly BSID1 BSID2 VPN1
+---------+ +---------+ +---------+
| | | | | |
CE1---*---------*----------*-*-*-*-*-*--------*-*-*-*-*-*---CE2
| | | | | |
+---------+ +---------+ +---------+
SRv6 Domain A SRv6 Domain B SRv6 Domain C
o No need to make any extensions in Control-Plane to (A1::1,BSID1)
advertise new type of SIDs or binding information. (VPN1,BSID2,BSID1)
(CE1, CE2)
o No indexed mapping table is required Figure 4.SRv6 Inter-domain Routing using BSID
o No routing extension is required. Normally, when a BSID is processed , a new IPv6 and SRH will be added
to the packet, and the SRH carries the SID list representing the sub-
path of this domain. C-SRH can be used to carry Compressed SID list
within the SRv6 domain for reducing the overhead of SRv6.
o No new routes advertisement is required if without new Locators In this way, a Binding SID can be associated with an SR Policy, which
contains a C-SID list to be carried by a C-SRH.
4. Hardware-friendly Therefore, in inter-domain SRv6 routing, C-SRH can be used in each
domain, while the SRH is used for inter-domian. In addition, if the
common prefixs of SIDs in SRH can be compressed, C-SRH can be used
for carring these SIDs as well.
o Hardware has the mature capability to overwrite the IPv6 DA. 9. Benefits
o Avoids any extra lookup in indexed mapping table 1. Seamless integration with SRv6 Network Programming
5. Efficient MTU overhead o No new type (Functions, such as END) of SRv6 SIDs is defined.
A C-SID is a sub-set of an SRv6 SID.
o C-SRH has the smallest MTU overhead among alternative solutions o Does not redefine the IPv6 address space nor requires any
(VxLAN with SR-MPLS, CRH, uSID), When all the Segment endpoint specific IPv6 space.
nodes information is maintained in the packet.
6. Scalable SR TE 2. Support for full set of SRv6 functionalities
o Full set of SRv6 functionality (BE, Loose TE and Strict TE, etc.)
are supported without any extra route advertisements.
o 8 C-SIDs can be carried in 128 bits when C-SID is 16 bits value o Function ID information is maintained.
o 16 Segment endpoint nodes (1 in DA and 16 in C-SRH including 3. Control-Plane friendly
the one in DA) in 40 bytes of overhead.
o T.Encaps with a C-SRH of 40 bytes (8 fixed + 2 * 16
bytes)
o ALL C-SIDs are maintained in C-SRH, which can be used o No need to make any extensions in Control-Plane to
for recording the explicit routing path. advertise new type of SIDs or binding information.
7. Saving IPv6 address o No indexed mapping table is required
o Very limited IPv6 address are needed for SID space. Longer o No routing extension is required.
Common Prefix means smaller IPv6 address burning and
smaller overhead of SRv6.
o Very easy to meet the requirement of C-SRH since any operator o No new route advertisement is required if without new Locators
or person can offer a 112/, 80/ or even 64/ prefix.
8. IANA Considerations 4. Hardware-friendly
o Hardware has the mature capability to overwrite the IPv6 DA.
o Avoids any extra lookup in indexed mapping table
5. Efficient MTU overhead
o C-SRH has the smallest MTU overhead among alternative solutions
(VxLAN with SR-MPLS, CRH, uSID), when all the Segment endpoint
nodes information is maintained in the packet.
6. Scalable SR TE
o 8 C-SIDs can be carried in 128 bits when C-SID is 16 bits value
o 16 Segment endpoint nodes (1 in DA and 16 in C-SRH including
the one in DA) in 40 bytes of overhead.
o T.Encaps with a C-SRH of 40 bytes (8 fixed + 2 * 16
bytes)
o ALL C-SIDs are maintained in C-SRH, which can be used
for recording the explicit routing path.
7. Saving IPv6 address
o Very limited IPv6 address are needed for SID space. Longer
Common Prefix means smaller IPv6 address burning and
smaller overhead of SRv6.
o Very easy to meet the requirement of C-SRH since any operator
or person can offer a 112/, 80/ or even 64/ prefix.
10. IANA Considerations
TBD TBD
9. Security Considerations 11. Security Considerations
TBD TBD
10. References 12. Contributors
10.1. Normative References Zhibo Hu
Huawei Technologies
huzhibo@huawei.com
Zhongzheng Wang
Huawei Technologies
wangzhongzhen@huawei.com
Bing Liu
Huawei Technologies
remy.liubing@huawei.com
Yang Xia
Huawei Technologies
yolanda.xia@huawei.com
Jianwei Mao
Huawei Technologies
MaoJianwei@huawei.com
13. Acknowledgements
14. References
14.1. Normative References
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
Routing Header (SRH)", draft-ietf-6man-segment-routing- (SRH)", draft-ietf-6man-segment-routing-header-26 (work in
header-21 (work in progress), June 2019. progress), October 2019.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
10.2. Informative References [I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extension to Support Segment Routing over
IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-04
(work in progress), January 2020.
[I-D.li-ospf-ospfv3-srv6-extensions]
Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
"OSPFv3 Extensions for SRv6", draft-li-ospf-
ospfv3-srv6-extensions-07 (work in progress), November
2019.
[I-D.ietf-pce-segment-routing-ipv6]
Negi, M., Li, C., Sivabalan, S., Kaladharan, P., and Y.
Zhu, "PCEP Extensions for Segment Routing leveraging the
IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-03
(work in progress), October 2019.
[I-D.ietf-idr-bgpls-srv6-ext]
Dawra, G., Filsfils, C., Talaulikar, K., Chen, M.,
daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link
State Extensions for SRv6", draft-ietf-idr-bgpls-
srv6-ext-02 (work in progress), January 2020.
[I-D.ietf-bess-srv6-services]
Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang,
S., and J. Rabadan, "SRv6 BGP based Overlay services",
draft-ietf-bess-srv6-services-01 (work in progress),
November 2019.
[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.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>.
14.2. Informative References
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 Matsushima, S., and Z. Li, "SRv6 Network Programming",
Network Programming", draft-ietf-spring-srv6-network- draft-ietf-spring-srv6-network-programming-08 (work in
programming-01 (work in progress), July 2019. progress), January 2020.
[I-D.filsfils-spring-srv6-net-pgm-illustration] [I-D.filsfils-spring-srv6-net-pgm-illustration]
Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., Filsfils, C., Camarillo, P., Li, Z., Matsushima, S.,
Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and
J. Leddy, "Illustrations for SRv6 Network Programming", J. Leddy, "Illustrations for SRv6 Network Programming",
draft-filsfils-spring-srv6-net-pgm-illustration-00 (work draft-filsfils-spring-srv6-net-pgm-illustration-01 (work
in progress), February 2019. in progress), August 2019.
Authors' Addresses Authors' Addresses
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
Cheng Li Cheng Li
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: chengli13@huawei.com Email: chengli13@huawei.com
Shuping Peng Chongfeng Xie
Huawei Technologies China Telecom
Huawei Campus, No. 156 Beiqing Rd. China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District
Beijing 100095 Beijing
China
Email: xiechf.bri@chinatelecom.cn
Daniel Voyer
Bell Canada
China China
Email: pengshuping@huawei.com Email: daniel.voyer@bell.ca
Zhongzheng Wang Kihoon LEE
Huawei Technologies LG U+
Huawei Campus, No. 156 Beiqing Rd. 71, Magokjungang 8-ro, Gangseo-gu
Beijing 100095 Seoul
Republic of Korea
Email: soho8416@lguplus.co.kr
Hui Tian
CAICT
Beijing
China China
Email: wangzhongzhen@huawei.com Email: tianhui@caict.ac.cn
Bing Liu
Feng Zhao
CAICT
Beijing
China
Email: zhaofeng@caict.ac.cn
James N Guichard
Futurewei Technologies
2330 Central Express Way
Santa Clara
USA
Email: james.n.guichard@huawei.com
Cong Li
China Telecom
China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District
Beijing
China
Email: licong.bri@chinatelecom.cn
Shuping Peng
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: remy.liubing@huawei.com Email: pengshuping@huawei.com
 End of changes. 103 change blocks. 
233 lines changed or deleted 658 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/