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]