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

Versions: 00

INTERNET-DRAFT                                                  Shen Yan
Intended Status: Informational                                  Zhe Chen
Expires: January 3, 2019                             Huawei Technologies
                                                            July 2, 2018


             The analysis of SRv6 and potential improvement
               draft-yan-rtgwg-srv6-constrain-analysis-00


Abstract

   This document analyzes the constrains of Segment Routing (SR),
   especially in the aspect of the header consumption and multicast of
   SRv6. Some potential methods have been proposed to improve the
   performance and enable more functions.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2018 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
   (http://trustee.ietf.org/license-info) in effect on the date of



Shen Yan etc.           Expires January 3, 2019                 [Page 1]


INTERNET DRAFT          SRv6 constrain analysis             July 2, 2018


   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 . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Constrain Analysis . . . . . . . . . . . . . . . . . . . . . .  3
     3.1  Segment Consumption . . . . . . . . . . . . . . . . . . . .  3
     3.2  Multicast . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4  Potential Improvement . . . . . . . . . . . . . . . . . . . . .  5
     4.1  Decrease the Consumption  . . . . . . . . . . . . . . . . .  5
     4.2  Globalize Semantics . . . . . . . . . . . . . . . . . . . .  6
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .  7
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  7
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1  Normative References  . . . . . . . . . . . . . . . . . . .  7
     7.2  Informative References  . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8


























Shen Yan etc.           Expires January 3, 2019                 [Page 2]


INTERNET DRAFT          SRv6 constrain analysis             July 2, 2018


1  Introduction

   Segment Routing (SR) leverages the source routing paradigm. It allows
   a headend node to steer a packet flow along any path for specific
   objectives like Traffic Engineering (TE). A node steers a packet
   through an SR Policy instantiated as an ordered list of instructions.
   These instructions are stack-structural and Segment Routing can be
   directly instantiated on the IPv6 data plane through the use of the
   Segment Routing Header defined in [I-D.ietf-6man-segment-routing-
   header]. SRv6 refers to this SR instantiation on the IPv6 data plane.
   The current SRv6's design is good however there are still some
   constrains in SID consumption and functional defects.

   In this document, we analyze the constrains of SRv6's design and try
   to propose the potential improvement methods.

2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


3.  Constrain Analysis

3.1  Segment Consumption

   The SID of SRv6 is a LOC:FUNCT tuple where FUNCT is a locally defined
   label. If a router is required to forward the packet to a specific
   neighbor, or perform a specific function, a corresponding label/SID
   MUST be put into the header. It means that N IPv6 addresses are
   needed in the header if the packet is required to pass through N
   routers.

   As shown in Figure 1, PE1 wants to transmit a flow to PE2. Each
   router in this path is required to execute the function of Rate Limit
   (RL). In this example, the total cost before the inner IP Packet will
   be 158 Bytes. This causes two problems. The first one is the low
   payload proportion. The average packet size on the Internet is around
   500 bytes and this design will occupy near 30%. The second one is the
   low processing efficiency. The current network processor reads
   normally less than 100 bytes at one time. If the header is too long,
   it needs more time to process. Conversely, if the header can be
   compressed shorter, the processing efficiency will be improved a
   lot.






Shen Yan etc.           Expires January 3, 2019                 [Page 3]


INTERNET DRAFT          SRv6 constrain analysis             July 2, 2018


     Function         Function         Function         +---------+
     = Rate Limit     = Rate Limit     = Rate Limit     |   MAC   |
                                                        +---------+
            +--+         +--+          +--+             | IPv6 HD |
      +---> |P1|    +--> |P3|     +--> |P5|             +---------+
      |     +-++    |    +-++     |    +-++             | P1::RL  |
      |       |     |      |      |      |              +---------+
      |       |     |      |      |      |              | P2::RL  |
      |       |     |      |      |      |              +---------+
      |       |     |      |      |      |              | ......  |
      |       |     |      |      |      |              +---------+
    +-+-+     |    ++-+    |    +-++     |    +---+     | PE2::E  |
    |PE1|     +--> |P2|    +-->-+P4|     +--> |PE2|     +---------+
    +---+          +--+         +--+          +---+     |IP Packet|
                                                        +---------+
              Function         Function
              = Rate Limit     = Rate Limit

                     Figure 1, Segment Consumption


   In this example, theoretically there are four redundant RL
   instructions. The potential improvements may come from two aspects.
   Firstly, the coupling of locator and function makes the segments
   cannot be reused. If the locator and function can be de-coupled by
   some methods, it potentially decreases the size of whole packet
   header especially when the number of routers is large and most of
   them execute the same function when forwarding the packet. Secondly,
   a simple path label may be employed instead of stacking multiple
   locators. A shorter path label can decrease the length of instruction
   list.


3.2  Multicast

   SR-MPLS supports multicast but SRv6 can hardly do the same. As shown
   in Figure 2, CE1, CE2, CE3, CE4 and CE5, construct a Blue VPN. CE1
   wants to send a broadcast frame to all the other CEs. Because of the
   localized semantics, different routers use different SIDs for the
   same instruction / metadata. Therefore, the multicast packet MUST be
   replicated at PE1 instead of the P-routers (P).

   In other words, in current SRv6 scheme, the multicast packet MUST be
   replicated at the ingress PE because egress PE uses different SIDs
   for the same VPN, since the locator is contained in SIDs. This is not
   an unsolvable problems. If the locator and function can be de-coupled
   meanwhile all the P-routers perform same operation according to a
   uniform instruction suite, all the multicast packets will be same in



Shen Yan etc.           Expires January 3, 2019                 [Page 4]


INTERNET DRAFT          SRv6 constrain analysis             July 2, 2018


   the egress router so that the packet could be replicated at any P-
   routers.

              M2            M3
         +-----------+ +-----------+
         |IPv6 Header| |IPv6 Header|
         +-----------+ +-----------+      --M2-->
         |SID=C2::20 | |SID=C3::30 |       +---+  +---+ C2::20 for
         +-----------+ +-----------+   +---|PE2+--+CE2| Blue VPN
         |  MAC PK   | |   MAC PK  |   |   +---+  +---+
         +-----------+ +-----------+   |
                                       |  --M3-->
   Blue VPN          ---M2--->         |   +---+  +---+ C3::20 for
                     ---M3--->         +---|PE3+--+CE3| Blue VPN
   +---+      +---+             +---+  |   +---+  +---+
   |CE1+------+PE1+-------------+ P +--+
   +---+      +---+             +---+  |  --M4-->
                     ---M4--->         |   +---+  +---+ C3::20 for
                     ---M5--->         +---|PE4+--+CE4| Blue VPN
              M4            M5         |   +---+  +---+
         +-----------+ +-----------+   |
         |IPv6 Header| |IPv6 Header|   |  --M5-->
         +-----------+ +-----------+   |   +---+  +---+ C3::20 for
         |SID=C4::40 | |SID=C5::50 |   +---|PE5+--+CE5| Blue VPN
         +-----------+ +-----------+       +---+  +---+
         |   MAC PK  | |   MAC PK  |
         +-----------+ +-----------+

                     Figure 2, Multicast with SRv6


4  Potential Improvement

   This section presents potential solutions to address the constrains
   discussed above.

   The core idea of the solutions is to de-couple instruction and
   locator carried in the data packet, by adopting globalized
   instructions. Globalized instruction is an instruction code that
   could be recognized by every node in a domain. Moreover, the packet
   processing logic associated with the instruction code SHOULD be same
   for all nodes in the domain. In this way, the packet header overhead
   could be significantly compressed, and multicast could be well
   supported.

4.1  Decrease the Consumption

   In particular, the example topology in Figure 1 could be used to



Shen Yan etc.           Expires January 3, 2019                 [Page 5]


INTERNET DRAFT          SRv6 constrain analysis             July 2, 2018


   illustrate this idea. To limit packet rate for a specific flow, the
   packets sent from PE1 to PE2 SHOULD carry two globalized
   instructions. One has the semantic of "shortest-path forwarding the
   packet according to PE2's address", and the other has the semantic of
   "limiting packet rate based on flow identifier and the maximal packet
   rate". Each node along the forwarding path performs these two
   globalized instructions accordingly thus achieving the targeted
   network function (i.e., packet rate limitation) with minimal overhead
   in the packet header.


    Function         Function         Function         +---------+
    = Rate Limit     = Rate Limit     = Rate Limit     |   MAC   |
                                                       +---------+
           +--+         +--+          +--+             |Func1=FWD|
     +---> |P1|    +--> |P3|     +--> |P5|             +---------+
     |     +-++    |    +-++     |    +-++             |Func2 =RL|
     |       |     |      |      |      |              +---------+
     |       |     |      |      |      |              | PE2_Addr|
     |       |     |      |      |      |              +---------+
     |       |     |      |      |      |              | Flow ID |
     |       |     |      |      |      |              +---------+
   +-+-+     |    ++-+    |    +-++     |    +---+     | Max PPS |
   |PE1|     +--> |P2|    +-->-+P4|     +--> |PE2|     +---------+
   +---+          +--+         +--+          +---+     |IP Packet|
                                                       +---------+
             Function         Function
             = Rate Limit     = Rate Limit

           Figure 3, Potential Solution for Speed Limitation


4.2  Globalize Semantics

   The example topology in Figure 2 could be used to illustrate how this
   idea benefits multicast scenarios. As shown in Figure 4, after
   receiving a broadcast Ethernet frame from CE1, the ingress node
   (i.e., PE1) only need to encapsulate the frame into a single packet,
   and the packet SHOULD carry two globalized instructions. One has the
   semantic of "forwarding and replicating (if needed) the packet
   according to the multicast address of group PE2-PE5", and the other
   has the semantic of "if there is no next-hop, striping the
   encapsulated instructions, looking up the VRF of blue VPN and
   forwarding the packet accordingly". Each transit node in the network
   forwards and replicates (if needed) the packet based on the multicast
   address, and the egress nodes perform corresponding VPN actions.
   Therefore, globalized instructions enable packet replication in
   transit nodes, thus eliminating bandwidth wasting.



Shen Yan etc.           Expires January 3, 2019                 [Page 6]


INTERNET DRAFT          SRv6 constrain analysis             July 2, 2018


                   +-----------+
                   | Func1=FWD |
                   +-----------+
                   | Func2=VPN |
                   +-----------+
                   |  MC_Addr  |
                   +-----------+           +---+  +---+ VPN ID 1000
                   |VPN ID=1000|       +---+PE2+--+CE2| for Blue VPN
                   +-----------+       |   +---+  +---+
                   |  MAC PK   |       |
                   +-----------+       |
   Blue VPN                            |   +---+  +---+ VPN ID 1000
                    ---------->        +---+PE3+--+CE3| for Blue VPN
   +---+      +---+             +---+  |   +---+  +---+
   |CE1+------+PE1+-------------+ P +--+
   +---+      +---+             +---+  |
                                       |   +---+  +---+ VPN ID 1000
                                       +---+PE4+--+CE4| for Blue VPN
                                       |   +---+  +---+
                                       |
                                       |
                                       |   +---+  +---+ VPN ID 1000
                                       +---+PE5+--+CE5| for Blue VPN
                                           +---+  +---+

             Figure 4, Potential Solution for Multicast VPN

   Note that the metadata (e.g., unicast and multicast IP addresses,
   flow identifier, maximal packet rate, and VPN identifier) associated
   with the globalized instructions should also be carried in the
   packets, and there should be an approach to efficiently organize
   those instructions and metadata into a reasonable packet format. Such
   an approach will be specified in separated documents.

5  Security Considerations


6  IANA Considerations


7  References

7.1  Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.





Shen Yan etc.           Expires January 3, 2019                 [Page 7]


INTERNET DRAFT          SRv6 constrain analysis             July 2, 2018


7.2  Informative References


   [SR-MPLS-MCAST] Dave Allan, etc., "A Framework for Computed Multicast
              Applied to SR-MPLS", Work in Progress, draft-allan-pim-sr-
              mpls-multicast-framework-00, June 1, 2018

   [SR-HEADER] C. Filsfils, Ed., etc., "IPv6 Segment Routing Header
              (SRH)", Work in Progress, draft-ietf-6man-segment-routing-
              header-14, June 28, 2018


Authors' Addresses


   Shen Yan
   Huawei Technologies Co. Ltd
   No. 156, Beiqing Rd,
   Haidian Dist, Beijing,
   China, 100095

   EMail: yanshen@huawei.com



   Zhe Chen
   Huawei Technologies Co. Ltd
   No. 156, Beiqing Rd,
   Haidian Dist, Beijing,
   China, 100095

   EMail: chenzhe17@huawei.com



















Shen Yan etc.           Expires January 3, 2019                 [Page 8]


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