Internet DRAFT - draft-cheng-spring-shorter-srv6-sid-requirement
draft-cheng-spring-shorter-srv6-sid-requirement
SPRING WG W. Cheng
Internet-Draft China Mobile
Intended status: Informational C. Xie
Expires: January 14, 2021 China Telecom
R. Pang
China Unicom
Z. Li
Huawei Technologies
R. Chen
ZTE Corporation
L. Zu
Unionpay
X. Duan
China Mobile
G. Mirsky
ZTE Corporation
D. Dukes
Cisco Systems, Inc
S. Zadok
Broadcom
July 13, 2020
Shorter SRv6 SID Requirements
draft-cheng-spring-shorter-srv6-sid-requirement-02
Abstract
This document describes a list of requirements for the use of a
shortened identifier in a segment routing network with the IPv6 data
plane.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021.
Cheng, et al. Expires January 14, 2021 [Page 1]
Internet-Draft Shorter SRv6 SID Requirements July 2020
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Typical Application Scenarios . . . . . . . . . . . . . . . . 3
4. Analysis of SRH Overhead . . . . . . . . . . . . . . . . . . 5
5. Gap Analysis of Existing Solutions . . . . . . . . . . . . . 6
5.1. Binding SID . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Loose Path TE . . . . . . . . . . . . . . . . . . . . . . 7
6. Requirements: . . . . . . . . . . . . . . . . . . . . . . . . 8
7. The proposal solutions of shorter SRv6 SID . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Segment routing (SR) [RFC8402] is a source routing paradigm that
explicitly indicates the forwarding path for packets at the ingress
node by inserting an ordered list of instructions, called segments.
A segment can be encoded as a Multi-Protocol Label Switching (MPLS)
label, IPv4 address, or IPv6 address. Segment Routing can be
deployed on the MPLS data plane by encoding 32-bits SIDs in MPLS
label stack [RFC8660]. It also can be deployed on the IPv6 data
plane by encoding a list of 128-bits SRv6 SIDs in IPv6 Segment
Routing Extension Header (SRH)[I-D.ietf-6man-segment-routing-header].
Cheng, et al. Expires January 14, 2021 [Page 2]
Internet-Draft Shorter SRv6 SID Requirements July 2020
The SRv6 Network Programming
[I-D.ietf-spring-srv6-network-programming] specifies the base set of
SRv6 behaviors that enables the creation of interoperable overlays
with underlay optimization.
However, the size of the SRv6 SID presents a scalabilities challenge
to use topological instructions that define a strict explicitly
routed path in combination with service-based instructions. At the
same time, the size of the SRH/SID may be a challenge for some data
plane processors and traffic overhead. Meanwhile, SR-MPLS currently,
more often than SRv6, is used in metro networks. With the gradual
deployment of SRv6 in the core networks, it becomes necessary to
support interworking between SR-MPLS and SRv6 and upgrading to SRv6
from SR-MPLS. It requires some solutions to resolve these problems.
2. Conventions used in this document
2.1. Terminology
SR: Segment Routing
SRH: Segment Routing Extension Header
MPLS: Multiprotocol Label Switching
SR-MPLS: Segment Routing over MPLS data plane
SID: Segment Identifier
SRv6: Segment Routing over IPv6
2.2. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Typical Application Scenarios
At present, only typical application scenarios are discussed, and
other scenarios will be considered in the next version.
In the scenario of the mobile backhaul network shown in Figure 1, the
eNodeB communicates with RC (Radio Controller). SRv6 path can be set
up between the ASGs (Access Site Gateway) and the RSG (RC Site
Gateway) to bear mobile services. For a strict SRv6 TE path in this
Cheng, et al. Expires January 14, 2021 [Page 3]
Internet-Draft Shorter SRv6 SID Requirements July 2020
scenarios, the typical number of the SIDs in the SRH is about 5 to 8
and the maximum is 10.
In the scenario of the mobile backhaul network, there are two
different domains. The domain between the ASGs and the AGGs
(Aggregation Gateway) is the access domain. And the domain between
the AGGs and the RSGs is the aggregation domain. The locators of the
SRv6 SIDs in each domain can share the common prefix. But the
locators of different domains may be different, meaning they cannot
share the common prefix.
eNodB2---ASG2-------AGG1------P1------RSG1------RC1
| | |
| | |
eNodB1---ASG1 | |
| | |
| | |
eNodB1---ASG3-------AGG2------P2------RC2-------RC2
Figure 1. Mobile Backhaul Network
In the scenario of multiple network domains shown in Figure 2, the
typical case is that Domain 1 and Domain 3 can be the mobile backhaul
networks and the Domain 2 can be the IP backbone network. An SRv6
path can be set up from the node in Domain 1 and end up at the node
in Domain 3 for bearing mobile services, which will travel multiple
network domains. In this case, the typical number of the SIDs in the
SRH for the E2E SRv6 path may be up to 15, that is, for each network
domain, the typical number of the SIDs in SRH for each network domain
is 5. Though Binding SIDs [RFC8402] can be used for shortening the
SIDs List.
In the scenario of multiple network domains, the locators of the SRv6
SIDs in each network domain can share the common prefix. But the
locators of different network domains may be different, meaning they
does not share the common prefix.
Cheng, et al. Expires January 14, 2021 [Page 4]
Internet-Draft Shorter SRv6 SID Requirements July 2020
A1--A3--ASBR11--ASBR21---P3--ASBR23--ASBR31--B3--B1
| | | | | |
| | | | | |
| Domain1 | | Domain2 | | Domain3 |
| | | | | |
| | | | | |
A2--A4--ASBR12--ASBR22--P4---ASBR24--ASBR32--B4--B2
Figure 2. Multiple Network Domains
4. Analysis of SRH Overhead
There are three major concerns about SRH overhead:
1. Path MTU
Since an SRv6 SID is a 128-bits value, when many SRv6 SIDs are
carried within an SRH, the large size overhead introduced by the SRH
increases the size of the packet which may exceed the Path MTU so
that the packet will be dropped.
In the current network, the PMTU of most UNI (User-to-Network
Interface) is configured as 1500 Bytes, due to the old link layer
technology in the user side. In most scenarios, such as IP WAN and
DCN, the PMTU of most NNI(Network-to-Network Interface) is configured
as 9000 bytes, since most vendors have to support Jumpo frame(>9000
Bytes). Therefore, when a packet come from the UNI, the packet size
is under 1500 bytes, which is far away from 9000 bytes even including
the overhead of SRH. So the Path MTU is not a critical issue in the
current network.
2. Forwarding Performance
As the size of the SRH overhead increases, it will bring burdens to
the hardware forwarding or software forwarding, and it will have
effect on the forwarding performance.
SRv6 can be deployed step-by-step in the networks while the hardware
capability is being developed. Given the fact some vendors already
supports the forwarding capability of up to 10 SIDs in the SRH now,
the challenges can be mitigated in the near future. But SRv6 will be
deployed in the wide network domains, the challenges to support more
SIDs in SRH still exist.
3. Payload Efficiency
Cheng, et al. Expires January 14, 2021 [Page 5]
Internet-Draft Shorter SRv6 SID Requirements July 2020
As the size of the SRH overhead increases, the ratio of the effective
payload of a packet will be decreased. The SRH overhead will cause
the waste of bandwidth.
According to the statistics information from AMS-IX
<https://stats.ams-ix.net/sflow/
index.html?type=;interval=monthly;counter=bps>, the average packet
size is about 512 Bytes. From throughput (in bps) point of view, the
packets large than 1024 bytes are more than 87% among the traffic.
Given the typical packet size and traffic statistics information, the
effect of payload efficiency can be under control with gradually
introducing of SRv6. However, in the long term there may be
requirements to insert up to 10 or more SIDs in an SRH which will low
down the payload efficiency.
In summary, according to the above analysis, the issue of SRv6 SRH
overhead can be under control in the short time. However, as the
development of SRv6 in the wider network domains, more SIDs will be
inserted in the SRH to support strict TE and other functionalities,
it will propose more challenges for the hardware.
5. Gap Analysis of Existing Solutions
5.1. Binding SID
The Binding SID [RFC8402] is bound to an SR Policy, instantiation of
which may involve a list of SIDs. Using BSID can shorten the SID
list [I-D.peng-spring-srv6-compatibility], and BSID is widely
deployed in the SR and SRv6 networks. However, the node that imposes
the bound policy needs to store the SID list, meaning the node should
maintain more states.
For example, the strict TE path <R1, R2, R3, R4, R5, R6, R7, R8, R9,
R10> can be represented as a series of END.X SIDs allocated by the
nodes, and the SID list can be represented as <R1-R2, R2-R3, R3-R4,
R4-R5, R5-R6, R6-R7, R7-R8, R8-R9, R9-R10>. BSID1 is bound to an SID
list <R2-R3, R3-R4, R4-R5, R5-R6>, BSID2 is bound to an SID list
<R6-R7, R7-R8, R8-R9, R9-R10>. Therefore, the path can be
represented as <R1-R2, BSID1, BSID2> by using the Binding SIDs. In
this way, the SID number in the SRH is reduced from 9 to 3. While
the drawback is that the states of Binding SIDs should be maintained
at the mapping nodes R2 and R6.
Cheng, et al. Expires January 14, 2021 [Page 6]
Internet-Draft Shorter SRv6 SID Requirements July 2020
++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ +
+ BSID1 BSID2 +
CPE1---R1---R2----R3----R4----R5----R6----R7----R8----R9--R10--CPE2
+ +
+ +
+ +
++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 2. Binding SID for Shorter the SID List
5.2. Loose Path TE
In some cases, if the strict TE path represented by an adjacency SID
list is the same as the loose TE path represented by a node SID or
prefix SID, the adjacency SID list can be replaced by the node SID or
the prefix SID to reduce the number of SIDs. However, loose path TE
can not guarantee the SLA of per-hop processing(bandwidth, delay,
etc.) for the traffic.
For example, an SRv6 policy explicitly indicates a strict TE path by
SID list <R1-R2, R2-R3, R3-R4, R4-R5, R5-R6, R6-R7, R7-R8, R8-R9,
R9-R10>. If this path is the same as the SPF path of an END SID S10
of node R10, then this END SID S10 can be used for forwarding the
traffic instead of the long SID list. However, if there are some SLA
policy associated to the Adjacency SIDs along the path, then it can
not be assured in best effort forwarding by using the END SID, even
the packet is forwarded following the same path.
++++++++++++++++++++++++++++++++++++++++++++++++++++
+ R11-------R12----R13 +
+ | | | +
+ | | | + END SID S10
CPE1---R1---R2----R3----R4----R5----R6----R7----R8----R9--R10--CPE2
+ | | +
+ | | +
+ R14-------------------------------R15 +
++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 3. Binding SID for Shorter SID List
Cheng, et al. Expires January 14, 2021 [Page 7]
Internet-Draft Shorter SRv6 SID Requirements July 2020
6. Requirements:
Based on the above typical scenario and gap analysis of existing
solutions , this section lists the suggested requirements for Shorter
SRv6 SID, which can be used to help the WG evaluate against the
proposed solutions:
REQ#1: The Shorter SRv6 solution MUST be compatible with the basic
SRv6. There are three basic Segment Routing over the IPv6 data-plane
(SRv6) documents:
o The Segment Routing (SR) architecture is defined in [RFC8402].
o The IPv6 Segment Routing Header (SRH) is defined in
[I-D.ietf-6man-segment-routing-header].
o SRv6 Network Programming is defined in
[I-D.ietf-spring-srv6-network-programming].
The Shorter SRv6 SID solution MUST be compatible with those defined
in above documents.
REQ#2: The Shorter SRv6 SID solution MUST support Efficient SRv6
header compression.
When SRv6 is deployed, the SRv6 header overhead must be considered,
as the size of the SRH may affect the forwarding performance. The
solution MUST reduce the SRv6 SID size effectively.
REQ#3: The Shorter SRv6 SID solution MUST support source routing,
SHOULD NOT introduce per-flow states on middle nodes.
Reducing the states on the middle nodes is the advantage of SR, and
it should be maintained. New states should be introduced after
carefully consideration if they are really needed.
REQ#4: A Shorter SRv6 SID solution SHOULD be routable as a Native
IPv6 address for typical applications.
It is the key feature of SRv6 that an SRv6 SID can be routable as a
native IPv6 address:
1. The feature guarantees the compatibility of SRv6 to IPv6.
2. Since an SRv6 SID is routable as a normal native IPv6 address,
the traffic can be forwarded as the normal IPv6 traffic on the SRv6
unaware nodes. It simplifies the service provision since SRv6-based
services can make use of the basic IPv6 reachability.
Cheng, et al. Expires January 14, 2021 [Page 8]
Internet-Draft Shorter SRv6 SID Requirements July 2020
3. The routes of SRv6 SIDs can be aggregated since SRv6 SID can be
routed as a native IPv6 address. This can reduce the number of
forwarding entries and improve the scalability, especially in inter-
AS networks scenarios.
4. Based on the native IPv6 routing, the SRv6 BE VPN can be deployed
by only upgrading the VPN endpoint nodes. Also, SRv6 VPN traffic can
be forwarded as the native IPv6 address without difficult
configurations on the edge nodes in inter-domain scenarios.
Therefore, the shorter SRv6 SID SHOULD be routable as a Native IPv6
address.
Other scenarios will be considered in future, the solution should
have the forward capabilities to support other scenarios.
REQ#5: The Shorter SRv6 SID solution CAN NOT require specific address
planning or address type.
When deploying SRv6 in a network, the SIDs can be allocated from a
SID space, the address block managed by the operators. The Shorter
SID solution should support this as well. It MUST support flexible
address planning as different networks have their own address
allocation policy. The Shorter SID MUST NOT depend on some specific
address type, and it SHOULD NOT introduce new address type in the
network since this increases the complexities of configurations and
operations, which will also bring troubles of OAM due to operators
may have limited experience of it.
REQ#6: The Shorter SRv6 SID solution MUST be a Loseless Compression
mechanism. The information carried by the shorter SID list in SRH
MUST be equivalent to the original SID list.
The information can not be lost in compression since each SID
represents the action and related services on a node, the Shorter SID
solution MUST represent the same function. The format of the Shorter
SID may be different from the original SRv6 SID, but the related
function should be identical.
REQ#7: The Shorter SRv6 SID solution SHOULD support multiple
functions, including END, END.X and END.T but not limit to them.
The solution MUST be scalable to support multiple functions and it
SHOULD NOT be limited in only END, END.X and END.T, since there will
be multiple SIDs to be introduced in the future, the solution should
have the forward capabilities to support the new SIDs.
Cheng, et al. Expires January 14, 2021 [Page 9]
Internet-Draft Shorter SRv6 SID Requirements July 2020
REQ#8: The Shorter SRv6 SID solution MUST be easy to implement and
hardware-friendly(Including ASIC-based and NP-based hardware)
The Shorter SRv6 SID solution MUST be simple and easy to implement
based on existing commercial hardware, which can be supported by
multiple vendors instead of some specific vendors.
REQ#9: The Shorter SRv6 SID solution MUST be compatible with SRv6
header(SRH).
For support of the SRv6 network, Segment Routing Header (SRH) has
been defined in [I-D.ietf-6man-segment-routing-header]. The Shorter
SRv6 SID solution MUST be compatible with SRH.
REQ#10: The Shorter SRv6 SID solution SHOULD support to encode
Compressed SRv6 Network Programming SIDs and SRv6 SIDs in a single
SRH.
In an SR domain, there will be a scenario in which some nodes support
Compressed SRv6, while others support IPv6 without SR extensions.
The proposed solution MUST support this scenario.
REQ#11: The Shorter SRv6 SID solution MUST support super-large-scale
networking and address planning.
Note: The operator suggest to reuse the current address assignment
and planning, thus minimizing the impact on the network.
REQ#12: The Shorter SRv6 SID solution MUST have the ability to
upgrade smoothly from SR-MPLS to SRv6.
2G/3G/4G backhaul networks widely deploy MPLS to connect wireless
services. Many operators are already deploying 5G networks. To
optimize the operation of the network, many operators intent to adopt
the segment routing. Currently, given the maturity of SR-MPLS, it
has been deployed on a large scale. Meanwhile the requirements of 5G
super-large-scale number of connections accelerate the deployment of
IPv6 networks. Thus, logically, operators consider SRv6 solution to
fulfill the 5G backhaul requirement. But the backhaul network could
not deploy SRv6 in one day, especially if it has already been using
MPLS and SR-MPLS. It might be reasonable to upgrade from MPLS to SR-
MPLS and then to SRv6.
REQ#13: The Shorter SRv6 SID solution MUST support interworking
between SRv6 and SR-MPLS domains in the network.
Cheng, et al. Expires January 14, 2021 [Page 10]
Internet-Draft Shorter SRv6 SID Requirements July 2020
SR-MPLS currently, more often than SRv6, is used in metro networks.
With the gradual deployment of SRv6 in the core networks, it becomes
necessary to support interworking between SR-MPLS and SRv6.
7. The proposal solutions of shorter SRv6 SID
As we know, there are several proposals in the shorter SRv6 SID
topic. This document tries to summarize these proposals here. Then
we can discuss whether all the proposals can meet the requirements.
And then we can look at the merits and costs of each solution. After
that, we will possibly refine them, possibly converge on a single
one, and probably drop multiples.
Here are the solutions that have been proposed:
o [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] defines a
compressed SRv6 network programming mechanism in order to reduce
the overhead of SRv6 by introducing the Compressed Segment
Identifier (C-SID). This solution leverages the SRv6 Network
Programming model and adds new flavors to enable a compressed
encoding of the SRv6 Segment-List in the SRH.
o [I-D.cl-spring-generalized-srv6-for-cmpr] proposes Generalized
Segment Routing over IPv6 (G-SRv6) Networking Programming, which
will remove the common prefix of SRv6 SIDs and supports to encode
multiple types of Segments in an SRH, called Generalized SRH
(G-SRH). These Segments can be called Generalized Segment, and
the ID can be Generalized Segment Identifier (G-SID), which may
include an SRv6 SID(128 bits), Shorter SID(32 bits or 16 bits).
o [I-D.filsfils-spring-net-pgm-extension-srv6-usid] extends SRv6
Network Programming with a new type of SRv6 SID behavior. A uSID
carrier can be encoded in the Destination Address of an IPv6
header or at any position in the Segment List of an SRH.
o [I-D.decraene-spring-srv6-vlsid] extends SRH and SRv6 Network
Programming to allow for SIDs of variable length, from 1 up to 128
bits. It is required to extend the control plane to advertise the
SID length.
o [I-D.bonica-6man-comp-rtg-hdr] defines two new Routing header
types. Collectively, they are called the Compressed Routing
Headers (CRH). Individually, they are called CRH-16 and CRH-32.
In the CRH, the Type-specific data field contains a list of
Segment Identifiers (SIDs)(16bits/32bits).
o [I-D.mirsky-6man-unified-id-sr] extends the use of the flag of the
SRH to unified identifiers encoded as shorter SID (such as
Cheng, et al. Expires January 14, 2021 [Page 11]
Internet-Draft Shorter SRv6 SID Requirements July 2020
32-bits). It can be interworking with SR-MPLS. It is the
earliest one, simple, and compatible well with original SRH.
8. IANA Considerations
This document has no requests to IANA.
9. Security Considerations
This document does not change the security considerations of SRv6,
please refers to [RFC8402], [I-D.ietf-6man-segment-routing-header]
and [I-D.ietf-spring-srv6-network-programming].
10. References
10.1. Normative References
[I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-26 (work in
progress), October 2019.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-16 (work in
progress), June 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
Cheng, et al. Expires January 14, 2021 [Page 12]
Internet-Draft Shorter SRv6 SID Requirements July 2020
10.2. Informative References
[I-D.bonica-6man-comp-rtg-hdr]
Bonica, R., Kamite, Y., Niwa, T., Alston, A., and L.
Jalil, "The IPv6 Compact Routing Header (CRH)", draft-
bonica-6man-comp-rtg-hdr-22 (work in progress), May 2020.
[I-D.cl-spring-generalized-srv6-for-cmpr]
Cheng, W., Li, Z., Li, C., Clad, F., Aihua, L., Xie, C.,
Liu, Y., and S. Shay, "Generalized SRv6 Network
Programming for SRv6 Compression", draft-cl-spring-
generalized-srv6-for-cmpr-01 (work in progress), May 2020.
[I-D.decraene-spring-srv6-vlsid]
Decraene, B., Raszuk, R., Li, Z., and C. Li, "SRv6 vSID:
Network Programming extension for variable length SIDs",
draft-decraene-spring-srv6-vlsid-03 (work in progress),
March 2020.
[I-D.filsfils-spring-net-pgm-extension-srv6-usid]
Filsfils, C., Camarillo, P., Cai, D., Voyer, D., Meilik,
I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman,
D., Liu, Y., and J. Guichard, "Network Programming
extension: SRv6 uSID instruction", draft-filsfils-spring-
net-pgm-extension-srv6-usid-07 (work in progress), May
2020.
[I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc]
Cheng, W., Filsfils, C., Li, Z., Cai, D., Voyer, D., Clad,
F., Shay, S., Guichard, J., and L. Aihua, "Compressed SRv6
Segment List Encoding in SRH", draft-filsfilscheng-spring-
srv6-srh-comp-sl-enc-01 (work in progress), May 2020.
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-ietf-spring-sr-service-
programming-02 (work in progress), March 2020.
[I-D.mirsky-6man-unified-id-sr]
Cheng, W., Mirsky, G., Peng, S., Aihua, L., and G. Mishra,
"Unified Identifier in IPv6 Segment Routing Networks",
draft-mirsky-6man-unified-id-sr-07 (work in progress),
July 2020.
Cheng, et al. Expires January 14, 2021 [Page 13]
Internet-Draft Shorter SRv6 SID Requirements July 2020
[I-D.peng-spring-srv6-compatibility]
Tian, H., Zhao, F., Xie, C., Li, T., Ma, J., Peng, S., Li,
Z., and J. Guichard, "SRv6 Compatibility with Legacy
Devices", draft-peng-spring-srv6-compatibility-02 (work in
progress), January 2020.
Authors' Addresses
Weiqiang Cheng
China Mobile
Email: chengweiqiang@chinamobile.com
Chongfeng
China Telecom
Email: xiechf.bri@chinatelecom.cn
Ran Pang
China Unicom
Email: pangran@chinaunicom.cn
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
Ran Chen
ZTE Corporation
Email: chen.ran@zte.com.cn
Lijun
Unionpay
Email: zulijun@unionpay.com
Xiaodong Duan
China Mobile
Email: duanxiaodong@chinamobile.com
Cheng, et al. Expires January 14, 2021 [Page 14]
Internet-Draft Shorter SRv6 SID Requirements July 2020
Greg Mirsk
ZTE Corporation
Email: gregimirsky@gmail.com
Darren Dukes
Cisco Systems, Inc
Email: ddukes@cisco.com
Shay Zadok
Broadcom
Email: shay.zadok@broadcom.com
Cheng, et al. Expires January 14, 2021 [Page 15]
