[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

SPRING Working Group                                            W. Cheng
Internet-Draft                                              China Mobile
Intended status: Standards Track                                   Z. Li
Expires: August 14, 2020                                           C. Li
                                                     Huawei Technologies
                                                                  C. Xie
                                                                   C. Li
                                                           China Telecom
                                                                 H. Tian
                                                                 F. Zhao
                                                                   CAICT
                                                       February 11, 2020


                  Generalized SRv6 Network Programming
                 draft-cl-spring-generalized-srv6-np-00

Abstract

   As the deployment of SRv6, some new requirements are proposed, such
   as SRv6 compression, transporting over SR-MPLS/MPLS and IPv4 domains.
   Therefore, it is necessary to consider other types of segments or
   sub-paths in the end-to-end SRv6 network programming.

   This document proposes Generalized Segment Routing over IPv6 (G-SRv6)
   Networking Programming, which supports to encode multiple types of
   Segments in a 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),
   C-SIDs, MPLS labels, or IPv4 tunnel information.

   This document also defines the mechanisms of Generalized SRv6
   Networking Programming and the requirements of related protocol
   extensions of control plane and 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




Cheng, et al.            Expires August 14, 2020                [Page 1]


Internet-Draft                   G-SRv6                    February 2020


   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 August 14, 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Crossing C-SRv6 Domains . . . . . . . . . . . . . . . . .   5
     3.2.  Crossing SR-MPLS Domains  . . . . . . . . . . . . . . . .   7
     3.3.  Crossing IPv4 Domains . . . . . . . . . . . . . . . . . .   8
   4.  Concept of Generalized SRv6 . . . . . . . . . . . . . . . . .   9
     4.1.  SRv6 G-SID  . . . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  Compression G-SID . . . . . . . . . . . . . . . . . . . .  10
     4.3.  MPLS G-SID  . . . . . . . . . . . . . . . . . . . . . . .  11
     4.4.  IPv4 G-SID  . . . . . . . . . . . . . . . . . . . . . . .  12
   5.  G-SRv6 for Crossing SRv6 Compression Domains  . . . . . . . .  13
     5.1.  Mechanisms  . . . . . . . . . . . . . . . . . . . . . . .  13
       5.1.1.  Compressable SID Indication . . . . . . . . . . . . .  13
       5.1.2.  C-SID Length Indication . . . . . . . . . . . . . . .  14
       5.1.3.  Start of Compression Indication . . . . . . . . . . .  14
       5.1.4.  End of Compression Indication . . . . . . . . . . . .  15
     5.2.  Illustration  . . . . . . . . . . . . . . . . . . . . . .  16
     5.3.  Effect on SRv6  . . . . . . . . . . . . . . . . . . . . .  18
     5.4.  Protocol Extensions Requirements  . . . . . . . . . . . .  19
       5.4.1.  Data Plane  . . . . . . . . . . . . . . . . . . . . .  19
       5.4.2.  Control Plane . . . . . . . . . . . . . . . . . . . .  19
   6.  G-SRv6 for Crossing SR-MPLS Domain  . . . . . . . . . . . . .  20
     6.1.  Mechanisms  . . . . . . . . . . . . . . . . . . . . . . .  20
       6.1.1.  Start of MPLS G-SID Indication  . . . . . . . . . . .  20



Cheng, et al.            Expires August 14, 2020                [Page 2]


Internet-Draft                   G-SRv6                    February 2020


       6.1.2.  End of MPLS G-SID Indication  . . . . . . . . . . . .  21
     6.2.  Illustration  . . . . . . . . . . . . . . . . . . . . . .  21
     6.3.  Effect on SRv6  . . . . . . . . . . . . . . . . . . . . .  22
     6.4.  Protocol Extensions Requirements  . . . . . . . . . . . .  23
       6.4.1.  Data Plane  . . . . . . . . . . . . . . . . . . . . .  23
       6.4.2.  Control Plane . . . . . . . . . . . . . . . . . . . .  23
   7.  G-SRv6 for Crossing IPv4 Domain . . . . . . . . . . . . . . .  24
     7.1.  Mechanism . . . . . . . . . . . . . . . . . . . . . . . .  24
       7.1.1.  Start of IPv4 G-SID Indication  . . . . . . . . . . .  24
       7.1.2.  IPv4 G-SID encoding . . . . . . . . . . . . . . . . .  25
     7.2.  Illustration  . . . . . . . . . . . . . . . . . . . . . .  25
     7.3.  Effect on SRv6  . . . . . . . . . . . . . . . . . . . . .  26
     7.4.  Protocol Extensions Requirements  . . . . . . . . . . . .  26
       7.4.1.  Data Plane  . . . . . . . . . . . . . . . . . . . . .  27
       7.4.2.  Control Plane . . . . . . . . . . . . . . . . . . . .  27
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  28
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  28
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  28
     12.2.  Informative References . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

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.

   When segment routing is deployed on the IPv6 data plane, it is called
   SRv6 [I-D.ietf-6man-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, has been defined in
   [I-D.ietf-6man-segment-routing-header].  In use cases like Traffic
   Engineering, an ordered SID List with multiple SIDs is inserted into
   the SRH to steer packets along an explicit path.

   As the deployment of SRv6, some new requirements are proposed, such
   as SRv6 compression, transporting over SR-MPLS/MPLS and IPv4 domains.
   Therefore, it is necessary to consider other types of segments or
   sub-paths in the end-to-end SRv6 network programming.

   This document proposes Generalized Segment Routing over IPv6 (G-SRv6)
   Networking Programming, which supports to encode multiple types of
   Segments in a SRH, called Generalized SRH (G-SRH).  These Segments
   can be called Generalized Segment, and the ID can be Generalized




Cheng, et al.            Expires August 14, 2020                [Page 3]


Internet-Draft                   G-SRv6                    February 2020


   Segment Identifier (G-SID), which may include an SRv6 SID(128 bits),
   C-SIDs, MPLS labels, or IPv4 tunnel information.

   This document also defines the mechanisms of Generalized SRv6
   Networking Programming and the requirements of related protocol
   extensions of control plane and data plane.

2.  Terminology

   This document makes use of the terms defined in
   [I-D.ietf-6man-segment-routing-header], [RFC8402] and [RFC8200], and
   the reader is assumed to be familiar with that terminology.  This
   document introduces the following terms:

   SRv6 SID: The 128-bit segment identifier is introduced in
   [I-D.ietf-spring-srv6-network-programming].  It is always composed by
   locator, function and/or arguments.

   C-SRv6: Compressed SRv6 Network Programming

   Compressable SID: It is the 128-bit SRv6 SID which can be compressed.
   It is composed by Common Prefix and Compressed Segment Identifier
   (C-SID) and optional arguments.

   Common Prefix: It is the same prefix shared by multiple Compressable
   SIDs.

   C-SID: Compressed Segment Identifier
   [I-D.li-spring-compressed-srv6-np].  It is the remaining part of
   Compressable SID removing Common Prefix and arguments.  The
   recommended length of C-SIDs is 32 bits.

   C-SRH: Compressed Segment Routing Header.  It is the enhanced SRH
   used for C-SRv6.

   G-SRv6: Generalized SRv6 Network Programming

   G-SID: Generalized Segment Identifier.

   G-SRH: Generalized Segment Routing Header.  It is the enhanced SRH
   used for G-SRv6.

   Compression G-SID: It is the G-SID for encapsulating C-SIDs.

   MPLS G-SID: It is the G-SID for encapsulating MPLS label stack
   encapsulation information.





Cheng, et al.            Expires August 14, 2020                [Page 4]


Internet-Draft                   G-SRv6                    February 2020


   IPv4 G-SID: It is the G-SID for encapsulating IPv4 tunnel
   information.

   SRv6 Compression Sub-path: It is the path for crossing the SRv6
   compression domain in the end-to-end G-SRv6 path.

   SR-MPLS Sub-path: It is the path for crossing the SR-MPLS domain in
   the end-to-end G-SRv6 path.

   IPv4 Tunnel Sub-path: It is the IPv4 tunnel path for crossing the
   IPv4 domain in the end-to-end G-SRv6 path.

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Requirements

   This section describes the requirements of G-SRv6.

3.1.  Crossing C-SRv6 Domains

   The overhead of SIDs (16 bytes per SID) in SRH proposes challenges
   for packet processing and payload efficiency.  For addressing this
   problem, some solutions are proposed.  For example,
   [I-D.li-spring-compressed-srv6-np] proposes Compressed SRv6 Network
   programming(C-SRv6).

   In an SRv6 domain, the SIDs will be allocated from an address block,
   called SID space.  For routing within an SRv6 domain, the SIDs may
   have the same prefix (Common Prefix).
   [I-D.li-spring-compressed-srv6-np] defines a compressed SID (C-SID)
   to carry the different part of the original SRv6 SID in the SRH.  The
   format of a compressable SRv6 SID with 32 bit C-SID is shown in
   Figure 1.  The argument part is specified by use cases, and it is
   zero by default.  It is shared by the compressable SRv6 SIDs in a
   C-SRv6 sub-path










Cheng, et al.            Expires August 14, 2020                [Page 5]


Internet-Draft                   G-SRv6                    February 2020


    0         Variable Length            32 bits                128 bits
    +--------------------------------------------------------------+
    |             Common Prefix   |  C-SID         | Argument      |
    +--------------------------------------------------------------+
    |<-------- Locator ---------------->|<-FuncID->|<--Argument -->|
                                  |<--->|
                                     |
                          Different part of Locator

             Figure 1. 32 bits C-SID in Compressable SRv6 SID


   In C-SRv6, the common prefix can be carried by the first SID in the
   IPv6 destination address, while only the C-SIDs of the original SIDs
   are carried in the C-SRH.  In this way, the overhead of SRv6 can be
   reduced.

   C-SRv6 can reduce the overhead of SRH.  But the C-SRv6 requires that
   all the SIDs of the SRv6 path to be the compressable SRv6 SID.  The
   limitation causes that it does not work in the following scenarios:

   Scenario 1-1:

   In a single domain owing to the incremental deployment there will be
   the scenario in which some nodes can support C-SRv6 while others only
   support SRv6.  This causes that the end-to-end SRv6 path may be
   composed by both SRv6 SIDs and Compressable SRv6 SIDs.  In this case
   C-SRv6 cannot work and SRH has to be used for the SRv6 path.

   For example, as illustrated in Figure 2, a packet is forwarded along
   the path A1->A2->A3->A4->A5->A6->A7, and the SRv6 SID list is
   [A::1:1, A::2:1, A::3:1, A::4:1, A::5:1, A6::6:1, A::7:10].  All the
   nodes along the path support compression except A6.  In this case,
   the SID list can not be compressed due to A6 does not support
   compression.

                   (A::3:1)  A3------A4  (A::4:1)
                              |      |
                   (A::2:1)  A2      A5  (A::5:1)
                              |      |
      Tenant10  CE1-----A0---A1------A6---A7-----CE3  Tenant10 with
                         (A::1:1)(A6::6:1) (A::7:10)      IPv4 20/8


        Figure 2. SRv6 Path with SRv6 SIDs and Compressable SIDs


   Scenario 1-2:



Cheng, et al.            Expires August 14, 2020                [Page 6]


Internet-Draft                   G-SRv6                    February 2020


   In C-SRv6, Common Prefix must be designed for the Compressable SRv6
   SIDs.  But in the scenario of crossing multiple SRv6 domains, it is
   very difficult to design the unified Common Prefix.  It can be easy
   to design its own Common Prefix in a single domain.  Thus an SRv6
   path crossing multiple domains may be composed by different groups of
   Compressable SRv6 SIDs with different Common Prefixes, and they can
   not be encoded in a single C-SRH.

   For example, as illustrated in Figure 3, , a packet is forwarded
   along the path A1->A2->A3->A4->B1->B2->B3->B4, and the SRv6 SID list
   is [A::1:1, A::2:1, A::3:1, A:4:1, B::1:1, B::2:1, B::3:1, B:4:1].
   The Common Prefix of the sub-path A1->A2->A3->A4 is A and the Common
   Prefix of the sub-path B1->B2->B3->B4 is B.  But the end-to-end SRv6
   path cannot be compressed in a single C-SRH.

                         A2-----A3    B2-----B3
                         |      |     |      |
                         |      |     |      |
                         |      |     |      |
   Tenant10  CE1---A0----A1-----A4----B1-----B4-----B0---CE3  Tenant10 with
                                                              IPv4 20/8

     Figure 3. SRv6 Path Crossing Multiple SRv6 Compression Domains


   For addressing above problems, a mechanism of encoding SRv6 SIDs and
   SRv6 C-SIDs in any order in an SRH should be provided, which does not
   require all the nodes along the path to support SRv6 compression.

3.2.  Crossing SR-MPLS Domains

   In SRv6, END.BM SID can be used for indicating an SR-MPLS Policy.
   Therefore, when an SRv6 packet needs to travel an SR-MPLS path, the
   associated END.BM SID should be encoded in the SID list.  When the
   packet arrives at the ingress node of the SR-MPLS path, an MPLS label
   stack will be encapsulated to the packet according to the END.BM, and
   the packet will be forwarded in the SR-MPLS domain based on the MPLS
   labels.

   End.BM hides the details of the SR-MPLS path, which brings benefits
   on security and privacy.  But it brings more network states to the
   intermediate nodes of the SRv6 path.  Also, when operators can manage
   both the SRv6 networks and SR-MPLS networks, it can program an end-
   to-end path under specific SLA assurance.  If the existing SR-MPLS
   path associated with END.BM can not meet the SLA requirement, then a
   new END.BM SID should be configured and advertised among the
   networks.  This procedure increases the complexities of deploying
   services.



Cheng, et al.            Expires August 14, 2020                [Page 7]


Internet-Draft                   G-SRv6                    February 2020


   For example, as illustrated in Figure 4, when a packet is sent from
   CE1 to CE3, it may choose several paths in SR-MPLS domain, which
   provide different SLA assurance.  Therefore, state of multiple SR-
   MPLS paths should be maintained at the node A1 and A2.

   - SR-MPLS Path 1: A1->A4->A5

   - SR-MPLS Path 2: A1->A2->A3->A6

   - SR-MPLS Path 3: A1->A2->A3->A6->A5

   - SR-MPLS Path 4: A2->A3->A6

   - SR-MPLS Path 5: A2->A1->A4->A5

   - SR-MPLS Path 6: A2->A1->A4->A5->A6

   There will be more states of path should be maintained when the scale
   of SR-MPLS domain is large.

                     B2-------A2----A3-----A6-------B3
                     |  SRv6  |   SR-MPLS  |  SRv6  |
                     | Domain |   Domain   | Domain |
                     |        |            |        |
     Tenant10  CE1---B1-------A1----A4-----A5-------B4---CE3  Tenant10 with
                                                                  IPv4 20/8

                Figure 4. SRv6 Path Crossing SR-MPLS Domains

   In order to program SR-MPLS sub-path more flexible and reduce the
   states on the intermediate nodes, a mechanism for encoding SRv6 SID
   and MPLS labels should be provided.  In this way, the ingress node of
   the path can program the end-to-end path including the SRv6 sub-path
   and the SR-MPLS sub-path, and no state of MPLS sub-path will be
   maintained.

3.3.  Crossing IPv4 Domains

   In some scenarios such as SD-WAN an SRv6 packet may cross an IPv4
   domain, and the SRv6 packets will be transported by the IPv6 over
   IPv4 tunnel.  Similar to SR-MPLS, there can be two options for
   indicating the IPv4 tunnel.

   o  Option A: the IPv4 tunnel binding SID in SRH

   o  Option B: the IPv4 tunnel parameters in SRH





Cheng, et al.            Expires August 14, 2020                [Page 8]


Internet-Draft                   G-SRv6                    February 2020


   For IPv4 tunnel binding SID, the ingress node of IPv4 tunnel should
   maintain the states of this tunnel.

   For example, as illustrated in Figure 5, when a packet is sent from
   CE1 to CE3, it may choose several paths in the IPv4 domain.
   Therefore, state of multiple IPv4 tunnels should be maintained at the
   node A1 and A2.

   - IPv4 Tunnel 1: Source Address A1, Destination Address A5

   - IPv4 Tunnel 2: Source Address A1, Destination Address A6

   - IPv4 Tunnel 3: Source Address A2, Destination Address A5

   - IPv4 Tunnel 4: Source Address A2, Destination Address A6

   There will be more states of IPv4 tunnels should be maintained when
   the scale of the IPv4 domain is large.

                     B2-------A2----A3-----A6-------B3
                     |  SRv6  |    IPv4    |  SRv6  |
                     | Domain |   Domain   | Domain |
                     |        |            |        |
     Tenant10  CE1---B1-------A1----A4-----A5-------B4---CE3  Tenant10 with
                                                                IPv4 20/8

                Figure 5. SRv6 Path Crossing IPv4 Domains

   The second option can be adopted to carry the IPv4 tunnel information
   explicitly in the SRH.  At the ingress of the IPv4 tunnel, an IPv4
   tunnel header will be encapsulated to the packet according to the
   IPv4 tunnel information in the SRH.  In order to support encoding
   IPv4 tunnel information in SRH, new mechanisms are required.

4.  Concept of Generalized SRv6

   According to the requirements described above, this document proposes
   Generalized SRv6, which supports to encode multiple types of Segment
   ID in a single SRH for an end-to-end Generalized SRv6 path that
   travels multiple types of networks, such as SRv6 domains, Compressed
   SRv6 domains, SR-MPLS domains and IPv4 domains.

   In order to support G-SRv6, this document proposes some enhancements
   of SRH.  This enhanced SRH is called Generalized SRH (G-SRH).  The
   Segments encoded in a G-SRH is called General Segments and its ID is
   called Generalized SID (G-SID).  A G-SID is a 128 bits value, and it
   may contain:




Cheng, et al.            Expires August 14, 2020                [Page 9]


Internet-Draft                   G-SRv6                    February 2020


   o  an SRv6 SID

   o  a compression G-SID

   o  an MPLS G-SID

   o  an IPv4 G-SID

4.1.  SRv6 G-SID

   SRv6 SID is a type of G-SID.  A G-SID contains a single SRv6 SID, and
   does not change anything of SRv6 SID.

4.2.  Compression G-SID

   As per [I-D.li-spring-compressed-srv6-np], a C-SID is a sub-set of a
   compressable SRv6 SID, which can be used for routing the packets in
   compressed SRv6 network programming.

   A compression G-SID shown in Figure 6 may contains several C-SIDs and
   optional padding.  When C-SID is a 32 bits value, a compression G-SID
   can consist of 4 C-SIDs.  If the length of C-SIDs in a G-SID is less
   than 128 bits, then padding is required.




























Cheng, et al.            Expires August 14, 2020               [Page 10]


Internet-Draft                   G-SRv6                    February 2020


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         C-SID 0                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         C-SID 1                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         C-SID 2                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         C-SID 3                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   (a)

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Padding                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Padding                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         C-SID 0                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         C-SID 1                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   (b)

                        Figure 6. Compression G-SID

4.3.  MPLS G-SID

   An MPLS G-SID shown in Figure 7 may contains 4 MPLS Label
   Encapsulations, if number of MPLS Label Encapsulations is less than
   4, then padding is required in G-SID for aligning with 128 bits.


















Cheng, et al.            Expires August 14, 2020               [Page 11]


Internet-Draft                   G-SRv6                    February 2020


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Label 0                     |  TC |S|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Label 1                     |  TC |S|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Label 2                     |  TC |S|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Label 3                     |  TC |S|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   (a)

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Padding                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Padding                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Label 0                     |  TC |1|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Label 1                     |  TC |S|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   (b)

                        Figure 7. MPLS G-SID


   In order to indicate the MPLS G-SID, this document proposes a END.M
   (End function with SR-MPLS path instantiation), this will be
   described in section 6.

   An MPLS G-SID appears after the END.M SID, and it can not be the last
   G-SID in the G-SID list.

4.4.  IPv4 G-SID

   An IPv4 G-SID shown in Figure 8 contains 128 bits IPv4 tunnel related
   information.  The format of IPv4 G-SID is shown below.











Cheng, et al.            Expires August 14, 2020               [Page 12]


Internet-Draft                   G-SRv6                    February 2020


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type  |               Tunnel Parameters                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       IPv4 Src Address                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       IPv4 Dest Address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Tunnel Parameters                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 8. IPv4 G-SID

   In order to indicate the IPv4 G-SID, this document proposes a END.4
   (End function with IPv4 tunnel instantiation), this will be described
   in section 7.  The detailed encoding of IPv4 tunnel G-SID is also
   described in section 7.

   An IPv4 G-SID appears after the End.4 SID, and it can not be the last
   G-SID in the G-SID list.

5.  G-SRv6 for Crossing SRv6 Compression Domains

   This section describes the mechanism of G-SRv6 for crossing SRv6
   Compression Domains.

5.1.  Mechanisms

   The path for crossing SRv6 Compression Domain is called Compressed
   SRv6 sub-path.  It should be encoded in any location of a G-SRH.
   There are following aspects should be considered in this mechanism:

   o  Compression SID indication

   o  C-SID length indication

   o  Start of C-SIDs indication

   o  End of C-SIDs indication

5.1.1.  Compressable SID Indication

   A new flavor can be introduced to indicate that an SRv6 SID is
   compressable.  There are two options for the definition of the
   flavor:





Cheng, et al.            Expires August 14, 2020               [Page 13]


Internet-Draft                   G-SRv6                    February 2020


   o  Option A: If the Compressable flavor is set for a specific SRv6
      SID, it means that the SRv6 SID can be used as normal SRv6 SID and
      also can be used as Compressable SRv6 SID.

   o  Option B: If the Compressable flavor is set for a specific SRv6
      SID, it means that the SRv6 SID can only be used as Compressable
      SRv6 SID.  In this option, if an SRv6 SID is already allocated and
      the compression requirement is proposed, a new SRv6 SID has to be
      allocated as the Compressable SRv6 SID for the same function.

   Though the Option B may use more SRv6 SIDs for the purpose of
   compression, it has much advantages in the incremental deployment.
   This document recommends the Option B.

5.1.2.  C-SID Length Indication

   Compresable SRv6 SID can be represented as Common Prefix +
   C-SID+(Optional) Argument.  There can be multiple options for the
   length of C-SID as follows:

   o  Option A: a variable length in bytes

   o  Option B: optional length such as 16/32/64 bits

   o  Option C: only one option, 32 bits

   Though the length of C-SID can be configured locally or advertised by
   protocol extensions, the different length of C-SID will increase the
   complexity of process of control plane and data plane which is not
   necessary.  This document recommends Option C which is a ideal
   tradeoff between the compression and the enough space for node ID and
   SRv6 Function.

5.1.3.  Start of Compression Indication

   In G-SRv6, if the SID list of an SRv6 sub-path consists of a list of
   compressable SIDs, it can be programmed as follows: the first
   compressable SID indicates the start of C-SRv6 sub-path, followed by
   compressable G-SIDs, which includes C-SIDs and padding if the number
   of (32 bits) C-SIDs is less than 4 in a G-SID.  The format of
   programmed SRv6 compression sub-path is shown in Figure 9.










Cheng, et al.            Expires August 14, 2020               [Page 14]


Internet-Draft                   G-SRv6                    February 2020


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                              ...                              .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Compression G-SID 1                        |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Compression G-SID 2                        |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Compressable SRv6 SID                      |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 9. G-SID list for SRv6 Compression Path


5.1.4.  End of Compression Indication

   Since C-SIDs and SRv6 SIDs can be encoded in any order in an SRH, a
   mechanism for indicating the end of compression is needed.  There are
   mainly two options for the indication of the end of compression as
   follows:

   o  Option A: an EOC (End of Compression) flavor is introduced when
      advertise Compressable SRv6 SID.  When the node determines the
      IPv6 destination address of SRv6 packet is the Compresable SRv6
      SID with EOC flavor, meaning the associated C-SID is the last
      C-SID in the G-SID, and it will skip the G-SID in which the
      corresponding C-SID located and read the following 128-bit SRv6
      SID.

   o  Option B: an EOC C-SID is introduced in the G-SID to indicate the
      end of the compression.  The length of EOC C-SID is a 32 bits
      value, and the it's value can be a well-known value such as 0 or a
      node allocated value.  If the number of C-SIDs in a Compression
      G-SID is less than 4, the EOC can be used as the . If there are 4
      C-SIDs in the last G-SID of Compressed SRv6 sub-path, it has to
      insert a G-SID composed by 4 EOCs.





Cheng, et al.            Expires August 14, 2020               [Page 15]


Internet-Draft                   G-SRv6                    February 2020


   The different options for indication of end of compression are shown
   in Figure 10.


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  C-SID 0 (EOC Flavor)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  C-SID 1 (Non-EOC Flavor)                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  C-SID 2 (Non-EOC Flavor)                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  C-SID 3 (Non-EOC Flavor)                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            (a) Option A

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                        G-SID (MBZ)                            |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         C-SID 0                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         C-SID 1                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         C-SID 2                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         C-SID 3                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            (b) Option B

                Figure 10. End of Compression Indication

5.2.  Illustration

   According to the above mechanisms, the scenarios shown in the section
   3.1 can be encoded as follows:

   Scenario 1-1:

   Assuming that

   o  A::1:1, A::2:1, A::3:1, A::4:1, A::5:1 are the Compressable SIDs.

   o  A::1:2, A::2:2, A::3:2, A::4:2, A::5:2 are the Compressable SIDs
      with EOC flavor.



Cheng, et al.            Expires August 14, 2020               [Page 16]


Internet-Draft                   G-SRv6                    February 2020


   The programmed G-SRv6 path A1->A2->A3->A4->A5->A6->A7 is shown in
   Figure 11:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           A::7:10                             |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           A6::6:1                             |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            5:2                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            4:1                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            3:1                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            2:1                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          A1::1:1                              |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 11. G-SRv6 Path for Scenario 1-1


   Scenario 1-2:

   The programmed G-SRv6 path A1->A2->A3->A4->B1->B2->B3->B4 is shown in
   Figure 12:














Cheng, et al.            Expires August 14, 2020               [Page 17]


Internet-Draft                   G-SRv6                    February 2020


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Padding                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            4:2                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            3:1                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            2:1                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            B::1:1                             |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Padding                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            4:2                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            3:1                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            2:1                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           A::1:1                              |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 12. G-SRv6 Path for Scenario 1-2


   In reduced mode, the SID A::1:1 can be removed from the G-SRH.

   The mechanism of indicating the C-SIDs within the G-SID will be
   described in the document of G-SRH.

5.3.  Effect on SRv6

   G-SRv6 provides the flexibility of encoding SRv6 SID and SRv6 C-SID
   in a single SRH, which supports to program an SRv6 path that consists
   of compression capable and compression incapable nodes.  In this
   case, G-SRv6 solves the problem of SRv6 overhead with a limited
   effect on SRv6.

   o  Independent with SRv6: G-SRv6 does not require that the SRv6 SID
      Space has the common prefix for supporting compression.  A new
      address block can be allocated for compressable SID, and the



Cheng, et al.            Expires August 14, 2020               [Page 18]


Internet-Draft                   G-SRv6                    February 2020


      common prefix of Compressable SIDs can be configured with
      appropriate length.

   o  Incremental upgrade: G-SRv6 does not require to upgrade all the
      nodes along the path to support SRv6 compression, they can be
      upgraded on demand to support compression.

5.4.  Protocol Extensions Requirements

   This section describes the protocol extension requirements.

5.4.1.  Data Plane

   REQ1-01: An SRv6 compression path can be represented as a G-SID list
   consists of a compressable SRv6 SID and Compression G-SIDs.

   REQ1-02: A Compression G-SID consists of at most 4 (32-bits) C-SIDs,
   if the number of C-SID is less than 4, then padding is required to
   align with 128 bits.

   REQ1-03: If the first Compressable SID is copied to the IPv6 DA, then
   the C-SIDs of the following G-SIDs should be read by the nodes along
   the SRv6 compression sub-path and the C-SID part in IPv6 DA should be
   replaced accordingly.

   REQ1-04: The last C-SID in the G-SIDs for the SRv6 compression sub-
   path should be the Compressable SRv6 SID with EOC flavor.

   REQ1-05: When process the Compressalbe SRv6 SID with EOC flavor in
   the IPv6 DA, the corresponding G-SID in the G-SRH should be skipped
   and the IPv6 DA should be updated by the following SRv6 SID if
   exists.

5.4.2.  Control Plane

   REQ1-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for
   SRv6 compression capabilities

   REQ1-12: ISIS/OSPF/BGP-LS/BGP extensions for advertising the
   Compression flavor for Compressable SIDs.

   REQ1-13: ISIS/OSPF/BGP-LS extensions for advertising the End-of-
   compression(EOC) flavor for Compressable SIDs.

   REQ1-14: ISIS/OSPF/BGP-LS/BGP extensions for advertising the format
   of Compressable SIDs.





Cheng, et al.            Expires August 14, 2020               [Page 19]


Internet-Draft                   G-SRv6                    February 2020


   REQ1-21: BGP SRv6 Policy extensions for advertising the G-SRv6 for
   SRv6 compression capabilities.

   REQ1-22: BGP SR Policy extensions for programming a G-SRv6 path
   combining with Compressable SRv6 SIDs and SRv6 SIDs.

   REQ1-31: PCEP SRv6 Policy extensions for advertising the G-SRv6 for
   SRv6 compression capabilities.

   REQ1-32: PCEP SR Policy extension for programming a G-SRv6 path
   combining with Compressable SRv6 SIDs and SRv6 SIDs.

   REQ1-33: PCEP extensions for programming a G-SRv6 path combining with
   Compressable SRv6 SIDs and SRv6 SIDs.

6.  G-SRv6 for Crossing SR-MPLS Domain

   This section describes the mechanism for encoding SRv6 SIDs and MPLS
   G-SID in a single G-SRH.

6.1.  Mechanisms

   The path for crossing SR-MPLS domain is called SR-MPLS sub-path.  It
   can be encoded in any location of G-SRH.  There are two aspects
   should be considered in this mechanism:

   o  Start of MPLS G-SIDs indication

   o  End of MPLS G-SIDs indication

6.1.1.  Start of MPLS G-SID Indication

   In order to indicate the start of MPLS G-SIDs, new SRv6 SIDs types
   should be defined.  This document defines an SID function to indicate
   the start of MPLS G-SIDs, called End.M ( End with MPLS labels).

   An SR-MPLS sub-path can be encoded in the G-SRH as follows:














Cheng, et al.            Expires August 14, 2020               [Page 20]


Internet-Draft                   G-SRv6                    February 2020


        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

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                            ...                                .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        MPLS G-SID 1                           |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        MPLS G-SID 2                           |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        End.M SRv6 SID                         |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 13. SR-MPLS Sub-path Encoding in G-SRH


   When a node processes an End.M SID, it copies the following MPLS
   label stack encapsulation information of SR-MPLS sub-path in the MPLS
   G-SIDs to the MPLS header, and set the IPv6 DA as the SRv6 SID
   following the last MPLS G-SID of the SR-MPLS sub-path, and then
   forward the packet according to the active MPLS label.

6.1.2.  End of MPLS G-SID Indication

   The S-bit in the MPLS label indicates the end of the MPLS label
   within the current MPLS G-SIDs sub-list.

   When the ingress node of the SR-MPLS sub-path reads the MPLS label
   stack encapsulation information until the Label with S-bit set.  If
   the S-bit is set for the label encapsulation, it will skip the G-SID
   in which the label locates and set the IPv6 DA of the SRv6 packet as
   the SRv6 SID following the G-SID if exists.

6.2.  Illustration

   According to the above mechanisms, the scenarios shown in the section
   3.2 can be encoded as follows:

   Assuming that



Cheng, et al.            Expires August 14, 2020               [Page 21]


Internet-Draft                   G-SRv6                    February 2020


   o  A::1:100 is the End.M SID allocated by the node A1 for crossing
      SR-MPLS domain.

   o  Label 1001, 1002, 1003, 1004, 1005 and 1006 are allocated as the
      node segment for A1/A2/A3/A4/A5/A6.

   The programmed G-SRv6 path B1->A1->A2->A3->A6->A5->B4 is shown in
   Figure 14:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            B::4:1                             |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           1005                        |  TC |1|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           1006                        |  TC |0|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           1003                        |  TC |0|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           1002                        |  TC |0|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         A::1:100 (End.M)                      |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           B::1:1                              |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 14. G-SRv6 Path for Sec 3.2


6.3.  Effect on SRv6

   G-SRv6 supports to program the SRv6 SID and SR-MPLS SID/MPLS label in
   a single G-SRH, which provides to encode the end-to-end G-SRv6 path
   across SRv6 domains and SR-MPLS/MPLS domains explicitly at the
   ingress node.  However, it also brings complexities of network
   programming, so this document suggests to upgrade the SR-MPLS nodes
   to support SRv6.




Cheng, et al.            Expires August 14, 2020               [Page 22]


Internet-Draft                   G-SRv6                    February 2020


6.4.  Protocol Extensions Requirements

   This section describes the protocol extension requirements of G-SRv6
   for MPLS G-SID.

6.4.1.  Data Plane

   REQ2-01: An MPLS path can be encoded in G-SRH as a series of G-SIDs
   including a 128-bit End.M SRv6 SID and a set of MPLS G-SIDs.

   REQ2-02: An MPLS G-SID can consist of up to 4 MPLS label/SR-MPLS SID,
   if the number of MPLS label/SR-MPLS SID is less than 4, padding is
   required to align with 128 bits.

   REQ2-03: An End.M SRv6 SID indicates the start of MPLS G-SID.

   REQ2-04: The SRv6 packet can be encapsulated with an outer MPLS
   header, and the MPLS header contains the MPLS labels carried by the
   MPLS G-SIDs.

   REQ2-05: When the label encapsulation with S-bit is set is read by
   the ingress node of the SR-MPLS sub-path, the corresponding G-SID
   should be skipped and the IPv6 DA should be updated by the following
   SRv6 SID if exists.

6.4.2.  Control Plane

   REQ2-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for
   MPLS capabilities

   REQ2-12: ISIS/OSPF/BGP-LS extensions for advertising the End.M SRv6
   SID.

   REQ2-21: BGP SR Policy extensions for advertising the G-SRv6 for MPLS
   capabilities

   REQ2-22: BGP SR Policy extensions for encoding G-SID list with SRv6
   SID and MPLS G-SID for G-SRv6 path.

   REQ2-31: PCEP SR Policy extensions for advertising the G-SRv6 for
   MPLS capabilities

   REQ2-31: PCEP SR Policy extensions for encoding G-SID list with SRv6
   SID and MPLS G-SID for G-SRv6 path.

   REQ2-33: PCEP extensions for encoding G-SID list with SRv6 SID and
   MPLS G-SID for G-SRv6 path.




Cheng, et al.            Expires August 14, 2020               [Page 23]


Internet-Draft                   G-SRv6                    February 2020


7.  G-SRv6 for Crossing IPv4 Domain

   This section describes the mechanism of G-SRv6 for crossing IPv4
   domain.

7.1.  Mechanism

   The path for crossing IPv4 domain is called IPv4 tunnel sub-path.  It
   should be encoded in any location of G-SRH.  There are two aspects
   should be considered in this mechanism:

   o  Start of IPv4 G-SID

   o  IPv4 G-SID encoding

7.1.1.  Start of IPv4 G-SID Indication

   In order to indicate the start of IPv4 G-SIDs, new SRv6 SIDs types
   should be defined.

   This document defines an SID function to indicate the start of IPv4
   G-SIDs, called End.4( End with IPv4 tunnel).

   When a node processes the End.4 SID, it encapsulates an outer IPv4
   tunnel header for the SRv6 packet based on the tunnel information
   carried by the following IPv4 G-SID, and set the IPv6 DA as the SRv6
   SID following the IPv4 G-SID, and then forwards the packet according
   to the IPv4 DA.

   An IPv4 tunnel sub-path can be encoded in the G-SRH as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          IPv4 G-SID                           |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SRv6 End.4 SID                         |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 15. IPv4 Tunnel Sub-path Encoding in G-SRH




Cheng, et al.            Expires August 14, 2020               [Page 24]


Internet-Draft                   G-SRv6                    February 2020


   Also, this document proposes the END.B4 (End bound to an IPv4 tunnel)
   SID.  A End.B4 is bound to an IPv4 tunnel.  When the node receives a
   packet with End.B4 SID, the packet should be steered into the binding
   IPv4 tunnel.

7.1.2.  IPv4 G-SID encoding

   An IPv4 GID contains the IPv4 tunnel information including tunnel
   type, source IPv4 address, destination IPv4 address and tunnel
   parameters.  Different types of IPv4 tunnels have specific
   parameters:

   o  IPv4 UDP tunnel: the tunnel parameters includes source port and
      destination port.

   o  IPv4 VXLAN tunnel: the tunnel parameters includes source port,
      destination port and VN ID.

   The detailed encapsulation formats for different types of IPv4 tunnel
   is out of scope of the document.

7.2.  Illustration

   According to the above mechanisms, the scenarios shown in the section
   3.3 can be encoded as follows:

   Assuming that

   o  A::1:200 is the End.4 SID allocated by the node A1 for crossing
      IPv4 domain.

   The programmed G-SRv6 path B1->A1->A6->B4 is shown in Figure 16:



















Cheng, et al.            Expires August 14, 2020               [Page 25]


Internet-Draft                   G-SRv6                    February 2020


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            B::4:1                             |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type  |                Tunnel Parameters                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       IPv4 Src Address (A1)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       IPv4 Dest Address (A6)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Tunnel Parameters                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         A::1:200 (End.IP4)                    |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           B::1:1                              |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 9. G-SRv6 Path for Sec 3.3


7.3.  Effect on SRv6

   G-SRv6 provides the capabilities for encoding IPv4 tunnel information
   and SRv6 SID within a single G-SRH, which brings benefits on end-to-
   end network programming on scenarios of packets traveling SRv6
   domains and IPv4 domains.  However, it also brings new complexities,
   so this document suggests to upgrade the IPv4 nodes to support IPv6
   or SRv6.

7.4.  Protocol Extensions Requirements

   This section describes the protocol extension requirements of G-SRv6
   for IPv4 G-SID.








Cheng, et al.            Expires August 14, 2020               [Page 26]


Internet-Draft                   G-SRv6                    February 2020


7.4.1.  Data Plane

   REQ3-01: An IPv4 tunnel can be encoded in G-SRH as series of G-SIDs
   including a 128 bit End.4 SRv6 SID and a set of IPv4 G-SIDs.

   REQ3-02: An IPv4 G-SID can consist of multiple IPv4 tunnel
   information, such as IPv4 source address and destination address of
   the tunnel endpoint.

   REQ3-03: An End.4 SRv6 SID indicates the start of IPv4 G-SID.

   REQ3-04: An End.B4 SRv6 SID indicates the IPv4 tunnel.

   REQ3-05: The SRv6 packet can be encapsulated with an outer IPv4
   tunnel header based on the parameters in the IPv4 G-SID.

   REQ3-06: After the tunnel information is read by the ingress node of
   the IPv4 tunnel sub-path, the corresponding G-SID should be skipped
   and the IPv6 DA should be updated by the following SRv6 SID if
   exists.

7.4.2.  Control Plane

   REQ3-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for
   IPv4 capabilities

   REQ3-12: ISIS/OSPF/BGP-LS extensions for advertising the End.4 SRv6
   SID.

   REQ3-13: ISIS/OSPF/BGP-LS extensions for advertising the End.B4 SRv6
   SID.

   REQ3-21: BGP SR Policy extensions for advertising the G-SRv6 for IPv4
   capabilities

   REQ3-22: BGP SR Policy extensions for encoding G-SID list with SRv6
   SID and IPv4 G-SID for G-SRv6 path.

   REQ3-31: PCEP SR Policy extensions for advertising the G-SRv6 for
   IPv4 capabilities

   REQ3-31: PCEP SR Policy extensions for encoding G-SID list with SRv6
   SID and IPv4 G-SID for G-SRv6 path.

   REQ3-33: PCEP extensions for encoding G-SID list with SRv6 SID and
   IPv4 G-SID for G-SRv6 path.





Cheng, et al.            Expires August 14, 2020               [Page 27]


Internet-Draft                   G-SRv6                    February 2020


8.  IANA Considerations

   TBD

9.  Security Considerations

   TBD

10.  Contributors

   Zhibo Hu
   Huawei Technologies
   huzhibo@huawei.com

   Yang Xia
   Huawei Technologies
   yolanda.xia@huawei.com



11.  Acknowledgements

12.  References

12.1.  Normative References

   [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>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [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.






Cheng, et al.            Expires August 14, 2020               [Page 28]


Internet-Draft                   G-SRv6                    February 2020


   [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>.

   [I-D.li-spring-compressed-srv6-np]
              Li, Z., Li, C., Xie, C., Voyer, D., LEE, K., Tian, H.,
              Zhao, F., Guichard, J., Cong, L., and S. Peng, "Compressed
              SRv6 Network Programming", draft-li-spring-compressed-
              srv6-np-01 (work in progress), January 2020.

12.2.  Informative References

   [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-09 (work in
              progress), February 2020.

   [I-D.filsfils-spring-srv6-net-pgm-illustration]
              Filsfils, C., Camarillo, P., Li, Z., Matsushima, S.,
              Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and
              J. Leddy, "Illustrations for SRv6 Network Programming",
              draft-filsfils-spring-srv6-net-pgm-illustration-01 (work
              in progress), August 2019.

   [I-D.tian-spring-srv6-deployment-consideration]
              Tian, H., Zhao, F., Xie, C., Li, T., Ma, J., Peng, S., Li,
              Z., and Y. Xiao, "SRv6 Deployment Consideration", draft-
              tian-spring-srv6-deployment-consideration-00 (work in
              progress), November 2019.

Authors' Addresses

   Weiqiang Cheng
   China Mobile

   Email: chengweiqiang@chinamobile.com


   Zhenbin Li
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com




Cheng, et al.            Expires August 14, 2020               [Page 29]


Internet-Draft                   G-SRv6                    February 2020


   Cheng Li
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: chengli13@huawei.com


Chongfeng Xie
China Telecom
China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District
Beijing
China

Email: xiechf.bri@chinatelecom.cn


Cong Li
China Telecom
China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District
Beijing
China

Email: licong.bri@chinatelecom.cn


   Hui Tian
   CAICT
   Beijing
   China

   Email: tianhui@caict.ac.cn


   Feng Zhao
   CAICT
   Beijing
   China

   Email: zhaofeng@caict.ac.cn










Cheng, et al.            Expires August 14, 2020               [Page 30]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/