idnits 2.17.1 draft-yan-rtgwg-srv6-constrain-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2117 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 91, but not defined == Unused Reference: 'KEYWORDS' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'SR-MPLS-MCAST' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'SR-HEADER' is defined on line 306, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Shen Yan 3 Intended Status: Informational Zhe Chen 4 Expires: January 3, 2019 Huawei Technologies 5 July 2, 2018 7 The analysis of SRv6 and potential improvement 8 draft-yan-rtgwg-srv6-constrain-analysis-00 10 Abstract 12 This document analyzes the constrains of Segment Routing (SR), 13 especially in the aspect of the header consumption and multicast of 14 SRv6. Some potential methods have been proposed to improve the 15 performance and enable more functions. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Constrain Analysis . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1 Segment Consumption . . . . . . . . . . . . . . . . . . . . 3 59 3.2 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4 Potential Improvement . . . . . . . . . . . . . . . . . . . . . 5 61 4.1 Decrease the Consumption . . . . . . . . . . . . . . . . . 5 62 4.2 Globalize Semantics . . . . . . . . . . . . . . . . . . . . 6 63 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1 Normative References . . . . . . . . . . . . . . . . . . . 7 67 7.2 Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1 Introduction 72 Segment Routing (SR) leverages the source routing paradigm. It allows 73 a headend node to steer a packet flow along any path for specific 74 objectives like Traffic Engineering (TE). A node steers a packet 75 through an SR Policy instantiated as an ordered list of instructions. 76 These instructions are stack-structural and Segment Routing can be 77 directly instantiated on the IPv6 data plane through the use of the 78 Segment Routing Header defined in [I-D.ietf-6man-segment-routing- 79 header]. SRv6 refers to this SR instantiation on the IPv6 data plane. 80 The current SRv6's design is good however there are still some 81 constrains in SID consumption and functional defects. 83 In this document, we analyze the constrains of SRv6's design and try 84 to propose the potential improvement methods. 86 2 Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 3. Constrain Analysis 94 3.1 Segment Consumption 96 The SID of SRv6 is a LOC:FUNCT tuple where FUNCT is a locally defined 97 label. If a router is required to forward the packet to a specific 98 neighbor, or perform a specific function, a corresponding label/SID 99 MUST be put into the header. It means that N IPv6 addresses are 100 needed in the header if the packet is required to pass through N 101 routers. 103 As shown in Figure 1, PE1 wants to transmit a flow to PE2. Each 104 router in this path is required to execute the function of Rate Limit 105 (RL). In this example, the total cost before the inner IP Packet will 106 be 158 Bytes. This causes two problems. The first one is the low 107 payload proportion. The average packet size on the Internet is around 108 500 bytes and this design will occupy near 30%. The second one is the 109 low processing efficiency. The current network processor reads 110 normally less than 100 bytes at one time. If the header is too long, 111 it needs more time to process. Conversely, if the header can be 112 compressed shorter, the processing efficiency will be improved a 113 lot. 115 Function Function Function +---------+ 116 = Rate Limit = Rate Limit = Rate Limit | MAC | 117 +---------+ 118 +--+ +--+ +--+ | IPv6 HD | 119 +---> |P1| +--> |P3| +--> |P5| +---------+ 120 | +-++ | +-++ | +-++ | P1::RL | 121 | | | | | | +---------+ 122 | | | | | | | P2::RL | 123 | | | | | | +---------+ 124 | | | | | | | ...... | 125 | | | | | | +---------+ 126 +-+-+ | ++-+ | +-++ | +---+ | PE2::E | 127 |PE1| +--> |P2| +-->-+P4| +--> |PE2| +---------+ 128 +---+ +--+ +--+ +---+ |IP Packet| 129 +---------+ 130 Function Function 131 = Rate Limit = Rate Limit 133 Figure 1, Segment Consumption 135 In this example, theoretically there are four redundant RL 136 instructions. The potential improvements may come from two aspects. 137 Firstly, the coupling of locator and function makes the segments 138 cannot be reused. If the locator and function can be de-coupled by 139 some methods, it potentially decreases the size of whole packet 140 header especially when the number of routers is large and most of 141 them execute the same function when forwarding the packet. Secondly, 142 a simple path label may be employed instead of stacking multiple 143 locators. A shorter path label can decrease the length of instruction 144 list. 146 3.2 Multicast 148 SR-MPLS supports multicast but SRv6 can hardly do the same. As shown 149 in Figure 2, CE1, CE2, CE3, CE4 and CE5, construct a Blue VPN. CE1 150 wants to send a broadcast frame to all the other CEs. Because of the 151 localized semantics, different routers use different SIDs for the 152 same instruction / metadata. Therefore, the multicast packet MUST be 153 replicated at PE1 instead of the P-routers (P). 155 In other words, in current SRv6 scheme, the multicast packet MUST be 156 replicated at the ingress PE because egress PE uses different SIDs 157 for the same VPN, since the locator is contained in SIDs. This is not 158 an unsolvable problems. If the locator and function can be de-coupled 159 meanwhile all the P-routers perform same operation according to a 160 uniform instruction suite, all the multicast packets will be same in 161 the egress router so that the packet could be replicated at any P- 162 routers. 164 M2 M3 165 +-----------+ +-----------+ 166 |IPv6 Header| |IPv6 Header| 167 +-----------+ +-----------+ --M2--> 168 |SID=C2::20 | |SID=C3::30 | +---+ +---+ C2::20 for 169 +-----------+ +-----------+ +---|PE2+--+CE2| Blue VPN 170 | MAC PK | | MAC PK | | +---+ +---+ 171 +-----------+ +-----------+ | 172 | --M3--> 173 Blue VPN ---M2---> | +---+ +---+ C3::20 for 174 ---M3---> +---|PE3+--+CE3| Blue VPN 175 +---+ +---+ +---+ | +---+ +---+ 176 |CE1+------+PE1+-------------+ P +--+ 177 +---+ +---+ +---+ | --M4--> 178 ---M4---> | +---+ +---+ C3::20 for 179 ---M5---> +---|PE4+--+CE4| Blue VPN 180 M4 M5 | +---+ +---+ 181 +-----------+ +-----------+ | 182 |IPv6 Header| |IPv6 Header| | --M5--> 183 +-----------+ +-----------+ | +---+ +---+ C3::20 for 184 |SID=C4::40 | |SID=C5::50 | +---|PE5+--+CE5| Blue VPN 185 +-----------+ +-----------+ +---+ +---+ 186 | MAC PK | | MAC PK | 187 +-----------+ +-----------+ 189 Figure 2, Multicast with SRv6 191 4 Potential Improvement 193 This section presents potential solutions to address the constrains 194 discussed above. 196 The core idea of the solutions is to de-couple instruction and 197 locator carried in the data packet, by adopting globalized 198 instructions. Globalized instruction is an instruction code that 199 could be recognized by every node in a domain. Moreover, the packet 200 processing logic associated with the instruction code SHOULD be same 201 for all nodes in the domain. In this way, the packet header overhead 202 could be significantly compressed, and multicast could be well 203 supported. 205 4.1 Decrease the Consumption 207 In particular, the example topology in Figure 1 could be used to 208 illustrate this idea. To limit packet rate for a specific flow, the 209 packets sent from PE1 to PE2 SHOULD carry two globalized 210 instructions. One has the semantic of "shortest-path forwarding the 211 packet according to PE2's address", and the other has the semantic of 212 "limiting packet rate based on flow identifier and the maximal packet 213 rate". Each node along the forwarding path performs these two 214 globalized instructions accordingly thus achieving the targeted 215 network function (i.e., packet rate limitation) with minimal overhead 216 in the packet header. 218 Function Function Function +---------+ 219 = Rate Limit = Rate Limit = Rate Limit | MAC | 220 +---------+ 221 +--+ +--+ +--+ |Func1=FWD| 222 +---> |P1| +--> |P3| +--> |P5| +---------+ 223 | +-++ | +-++ | +-++ |Func2 =RL| 224 | | | | | | +---------+ 225 | | | | | | | PE2_Addr| 226 | | | | | | +---------+ 227 | | | | | | | Flow ID | 228 | | | | | | +---------+ 229 +-+-+ | ++-+ | +-++ | +---+ | Max PPS | 230 |PE1| +--> |P2| +-->-+P4| +--> |PE2| +---------+ 231 +---+ +--+ +--+ +---+ |IP Packet| 232 +---------+ 233 Function Function 234 = Rate Limit = Rate Limit 236 Figure 3, Potential Solution for Speed Limitation 238 4.2 Globalize Semantics 240 The example topology in Figure 2 could be used to illustrate how this 241 idea benefits multicast scenarios. As shown in Figure 4, after 242 receiving a broadcast Ethernet frame from CE1, the ingress node 243 (i.e., PE1) only need to encapsulate the frame into a single packet, 244 and the packet SHOULD carry two globalized instructions. One has the 245 semantic of "forwarding and replicating (if needed) the packet 246 according to the multicast address of group PE2-PE5", and the other 247 has the semantic of "if there is no next-hop, striping the 248 encapsulated instructions, looking up the VRF of blue VPN and 249 forwarding the packet accordingly". Each transit node in the network 250 forwards and replicates (if needed) the packet based on the multicast 251 address, and the egress nodes perform corresponding VPN actions. 252 Therefore, globalized instructions enable packet replication in 253 transit nodes, thus eliminating bandwidth wasting. 255 +-----------+ 256 | Func1=FWD | 257 +-----------+ 258 | Func2=VPN | 259 +-----------+ 260 | MC_Addr | 261 +-----------+ +---+ +---+ VPN ID 1000 262 |VPN ID=1000| +---+PE2+--+CE2| for Blue VPN 263 +-----------+ | +---+ +---+ 264 | MAC PK | | 265 +-----------+ | 266 Blue VPN | +---+ +---+ VPN ID 1000 267 ----------> +---+PE3+--+CE3| for Blue VPN 268 +---+ +---+ +---+ | +---+ +---+ 269 |CE1+------+PE1+-------------+ P +--+ 270 +---+ +---+ +---+ | 271 | +---+ +---+ VPN ID 1000 272 +---+PE4+--+CE4| for Blue VPN 273 | +---+ +---+ 274 | 275 | 276 | +---+ +---+ VPN ID 1000 277 +---+PE5+--+CE5| for Blue VPN 278 +---+ +---+ 280 Figure 4, Potential Solution for Multicast VPN 282 Note that the metadata (e.g., unicast and multicast IP addresses, 283 flow identifier, maximal packet rate, and VPN identifier) associated 284 with the globalized instructions should also be carried in the 285 packets, and there should be an approach to efficiently organize 286 those instructions and metadata into a reasonable packet format. Such 287 an approach will be specified in separated documents. 289 5 Security Considerations 291 6 IANA Considerations 293 7 References 295 7.1 Normative References 297 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 7.2 Informative References 302 [SR-MPLS-MCAST] Dave Allan, etc., "A Framework for Computed Multicast 303 Applied to SR-MPLS", Work in Progress, draft-allan-pim-sr- 304 mpls-multicast-framework-00, June 1, 2018 306 [SR-HEADER] C. Filsfils, Ed., etc., "IPv6 Segment Routing Header 307 (SRH)", Work in Progress, draft-ietf-6man-segment-routing- 308 header-14, June 28, 2018 310 Authors' Addresses 312 Shen Yan 313 Huawei Technologies Co. Ltd 314 No. 156, Beiqing Rd, 315 Haidian Dist, Beijing, 316 China, 100095 318 EMail: yanshen@huawei.com 320 Zhe Chen 321 Huawei Technologies Co. Ltd 322 No. 156, Beiqing Rd, 323 Haidian Dist, Beijing, 324 China, 100095 326 EMail: chenzhe17@huawei.com