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]