idnits 2.17.1 draft-li-mpls-global-label-usecases-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 17, 2015) is 3113 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3107' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC4761' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'RFC6391' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'RFC6790' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC7274' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC7432' is defined on line 464, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-bryant-mpls-flow-ident-02 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-05 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-06 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft Q. Zhao 4 Intended status: Informational Huawei Technologies 5 Expires: April 19, 2016 T. Yang 6 China Mobile 7 R. Raszuk 8 Individual 9 L. Fang 10 Microsoft 11 October 17, 2015 13 Usecases of MPLS Global Label 14 draft-li-mpls-global-label-usecases-03 16 Abstract 18 As the MPLS technologies develop, MPLS label is not only used with 19 the local meaning which is always be understood by the upstream node 20 and the downstream node, but also used with the global meaning which 21 can be understood by all nodes or part of nodes in the network. The 22 document defines the latter as the global label and proposes the 23 possible use cases of global label. In these usecases MPLS global 24 label can be used for location identification, VPN identification, 25 segment routing, etc. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 19, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Location Identification . . . . . . . . . . . . . . . . . 3 71 3.2. VPN Identification . . . . . . . . . . . . . . . . . . . 4 72 3.2.1. Flow Label of VPN LSP . . . . . . . . . . . . . . . . 4 73 3.2.2. Aggregate MVPN/VPLS over Single P-Tunnel . . . . . . 5 74 3.3. Segment Routing . . . . . . . . . . . . . . . . . . . . . 5 75 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 7.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 In the traditional MPLS architecture, MPLS label is always 86 distributed from the downstream node to the upstream node by LDP, 87 RSVP-TE and MP-BGP. These label mappings always have the local 88 meaning which can only be understood by the upstream node and the 89 downstream node. As the MPLS technologies develop, there proposes 90 possible usecases in which MPLS label mapping can be advertised to 91 all nodes or part of nodes in the network. That is, the meaning of 92 the label mapping will be understood by all nodes or part of nodes in 93 the network other than the local upstream node and downstream node. 94 This document defines such type of MPLS label as global label as the 95 opposite of local label. 97 In the MPLS world there are another pair of label related concepts: 98 per-platform label space [RFC3031]and context-specific label 99 space[RFC5331]. According to [RFC3031] MPLS local label can be 100 allocated from per-platform label space and per-interface label space 101 (in [RFC5331], per-interface label space is generalized as one type 102 of context-specific label space). MPLS global label can also be 103 allocated from per-platform label space or context-specific label 104 space. 106 The document proposes the possible usecases of MPLS global label. In 107 these usecases MPLS global label can be used for location 108 identification, VPN identification, segment routing, etc. 110 2. Terminology 112 CE: Customer Edge 114 MP2P: Multi-Point to Point 116 MP2MP: Multi-point to Multi-point 118 MVPN: Multicast VPN 120 P2MP: Point to Multi-Point 122 P2P: Point to Point 124 PE: Provider Edge 126 3. Use Cases 128 3.1. Location Identification 130 [I-D.bryant-mpls-flow-ident] and 131 [I-D.bryant-mpls-synonymous-flow-labels] propose the challenge of the 132 measurement of packet loss for the multi-point to point LSP. In this 133 case the same label is normally used by multiple ingress or upstream 134 LSRs for specific prefixes and hence source identification is not 135 possible by inspection of the top label by the egress LSRs. Thus 136 [I-D.bryant-mpls-synonymous-flow-labels] proposes the synonymous flow 137 label to be used to introduce some source specific information 138 encapsulated in the packet to identify packet batches from a specific 139 source. 141 MPLS LDP LSP is one type of multi-point to point LSP. As the network 142 convergence develops, MPLS LDP network needs to interwork with MPLS 143 TE/MPLS-TP network and unified MPLS OAM becomes the realistic 144 requirement. In this usecase, MPLS global label can be allocated for 145 each network node and advertised in the network. When implement the 146 measurement of packet loss for LDP LSP, such MPLS global label can be 147 used as the flow label to identify the source node of the LDP LSP. 148 When the destination receives the packets it can differentiate flows 149 from specific source node based on the advertised global label 150 binding information for network nodes. In this usecase, MPLS global 151 label is used as the unique identification of source nodes in the 152 network and may save the complex flow label negotiation process 153 between the source node and the destination node. 155 3.2. VPN Identification 157 MPLS global label can be allocated for VPN and advertised in the 158 network. In this usecase, MPLS global label is used as the unique 159 identification of VPN in the network and can be used for multiple 160 purposes. 162 3.2.1. Flow Label of VPN LSP 164 BGP VPN LSP is another type of multi-point to point LSP which faces 165 the challenge of the measurement of packet loss proposed by 166 [I-D.bryant-mpls-flow-ident] and 167 [I-D.bryant-mpls-synonymous-flow-labels]. In this usecase, the flow 168 label should be introduced to identfication of the source VPN. There 169 are two possible ways to use global label as the flow label: 171 Option 1: The global label is allocated for the same VPN on all PE 172 nodes and advertised in the network. And global labels can be 173 allocated for PE nodes and advertised in the network. Then the flow 174 label should be the source PE label + the VPN label shown in the 175 figure 1. 177 +-----------------+ 178 | | 179 +-----------------+ \ | Source PE | 180 | | -------\ | Global Label | 181 | Flow Label | -------/ +-----------------+ 182 | | / | | 183 +-----------------+ | VPN | 184 | Label | 185 +-----------------+ 187 Figure 1: Flow Label using Two Layers of Global Label 189 Option 2: The global label is allocated directly for source VPN 190 (ideentified by the pair of { Source PE, VPN }) and advertised in the 191 network. We call such label as Source VPN label. The flow label 192 should be the source VPN label shown in the figure 2. 194 +-----------------+ \ +-----------------+ 195 | | -------\ | | 196 | Flow Label | -------/ | Source VPN | 197 | | / | Global Label | 198 +-----------------+ +-----------------+ 200 Figure 2: Flow Label using One Layer of Global Label 202 No matter option 1 or option 2 is adopted, when the destination 203 receives the packets it can differentiate flows from specific source 204 VPN based on the advertised global label binding information. 206 3.2.2. Aggregate MVPN/VPLS over Single P-Tunnel 208 In BGP-base Multicast VPN ( [RFC6513]) and VPLS Multicast( 209 [RFC7117]), in order to implement aggregating multiple MVPN/VPLS 210 Instances on a single P-Tunnel (i.e. sharing one P2MP LSP) , context- 211 specific label is introduced to identify the MVPN/VPLS instance and 212 the label binding is allocated by the root PE and advertised to the 213 leaf PEs. In this usecase the context-specific label is one type of 214 global label to uniquely identify the MVPN/VPLS instance in the 215 network. 217 The context-specific label can solve the issue of aggregating 218 multiple MVPNs or VPLS instances over a single P2MP LSP. But if the 219 MP2MP LSP is adopted for aggregating multiple MVPN/VPLS instances the 220 solution does not work since there are multiple root PEs which may 221 allocate the same context-specific label for different MVPN/VPLS 222 instances. In order to solve the issue the global label can be 223 allocated to the same MVPN/VPLS instance on all PEs and advertised in 224 the network. Then the global label will become the unique 225 identification of VPN instance in the network. When aggregating 226 multiple MVPNs or VPLS instances over one MP2MP LSP, the 227 corresponding MPLS global label binding with the MVPN/VPLS instance 228 can be encapsulated by the root PE. Then the leaf PEs can determine 229 the MVPN or VPLS instance the received packets belong to based on the 230 advertised global label binding information for MVPN/VPLS instances. 231 The solution can provide the unified solution for aggregating 232 multiple MVPN/VPLS instances over P2MP LSP and MP2MP LSP. And the 233 solution can save the complex control plane and forwarding plane 234 process of context-specific label. 236 3.3. Segment Routing 238 Segment Routing [I-D.ietf-spring-segment-routing] is introduced to 239 leverage the source routing paradigm for traffic engineering, fast 240 re-route, etc. A node can steer a packet through an ordered list of 241 segments. A segment can represent any instruction, topological or 242 service-based. Segment Routing can be directly applied to the MPLS 243 architecture with no change on the forwarding plane in which a 244 segment can be encoded as an MPLS label and an ordered list of 245 segments can be encoded as a stack of labels. 247 Segment Routing [I-D.ietf-spring-segment-routing] introduces some 248 segments such as node segment, adjacency segment, etc. SR Global 249 Block (SRGB) is also introduced for allocation of segment. In the 250 MPLS architecture, SRGB is the set of local labels reserved for 251 global segments. When the global segment index is advertised, it can 252 be transited to MPLS label based on the SRGB. According to 253 [I-D.ietf-ospf-segment-routing-extensions] and 254 [I-D.ietf-isis-segment-routing-extensions] MPLS global label binding 255 information can also be directly advertised in the network. For 256 example, in the section 2.1 of 257 [I-D.ietf-ospf-segment-routing-extensions], when the Length field of 258 SID/Label Sub-TLV is set as 3, it will represent the label which can 259 be flooded in the whole network. By this method MPLS global label 260 can be directly allocated for specific node or adjacency, etc. and 261 advertised in the network. The solution can save the complex process 262 of SRGB advertisement and transition from the global Segment ID to 263 MPLS label. 265 4. Discussion 267 In the MPLS world, we can adopt the dichotomy to divide it into per- 268 platform label space and context-specific label space. 270 MPLS World 272 +-----------------+-----------------+ 273 | | | 274 | Per-Platform | Context-Specific| 275 | Label Space | Label Space | 276 | | | 277 +-----------------+-----------------+ 279 When we adopt another dichotomy to divide the MPLS world into local 280 label and global label, we may face more challenges. 282 MPLS World 284 Local Label vs. Global Label 285 +------------------------------+--------------------------------------+ 286 | | Special Purpose Label (RFC 7274) | 287 | |--------------------------------------+ 288 | | MPLS Upstream Label Assignment | 289 | | /Context-Specific Label Space | 290 | | (RFC 5331) | 291 | |--------------------------------------+ 292 | LDP (RFC 5036) | Entropy Label (RFC 6790) | 293 | RSVP-TE (RFC 3209) | Flow Label (RFC 6391) | 294 | BGP LSP (RFC 3107) |--------------------------------------+ 295 | L3VPN (RFC 4364) | BGP-base VPLS (RFC 4761) | 296 | LDP-based L2VPN (RFC 4762) | Segment Routing | 297 | EVPN (RFC 7432) | (draft-ietf-spring-segment-routing) | 298 | +--------------------------------------+ 299 | | Domain-Wide Label | 300 | | (Usecases: Synonymous Label/ | 301 | | Segment Routing, etc.) | 302 +---------------------------------------------------------------------+ 304 Figure 3: Division of MPLS World Using Local Label and Global Label 306 In the figure 3, we can easily understand the local label using for 307 LDP, RSVP-TE, label BGP, L3VPN, LDP-based L2VPN, EVPN,etc. But for 308 the opposite of these applications there may be many usecases which 309 are different from each other, but share the common characteristic 310 that the label meaning can be understood by all network nodes or part 311 of network nodes instead of only the local downstream nodes and 312 upstream nodes for which in this document such lable is defined as 313 global label : 315 -- For special purpose labels, their meaning can be understood by all 316 nodes in the MPLS network. Should they belong to global label? 318 -- For MPLS upstream label assignment in context-specific label 319 space, all downstream nodes can understand the meaning of the label 320 allocated by the upstream node binding for specific MVPN/VPLS 321 instance. We can see the root PE as one type to central controlled 322 node to allocate label to all leaf nodes. And thinking about the 323 uniqueness of the context determine by the shared P-tunnel, these 324 labels in fact are also unique in the network. Should they belong to 325 global label? 327 -- For entropy label and flow label, the label is calculated by the 328 ingress node based on specific hash algorithms which is totally 329 different from the local label distributed in the MPLS control plane. 331 And all nodes along the path will parse the label and according to 332 the uniform meaning to use the label for ECMP. But the label values 333 can be duplicate since they are calculated by different ingress 334 nodes. Should they belong to global label? 336 -- For BGP-based VPLS and Segment Routing, they can adopt the local 337 label block. But they introduce the global ID and transit them into 338 the local label. Especially for segment routing, when all nodes in 339 the network adopts the same SRGB, the global segment ID is easily 340 transited to a unique global label value in the network. Should they 341 belong to global label? 343 -- This document proposes some usecases to directly allocate the 344 unique label value and advise the label binding in the network. 345 Should they be directly called as global label or Domain-Wide label 346 as one type of global label? 348 Since above applications which are different from the traditional 349 MPLS local label, can we define all of them as global label or define 350 some of them as global label and bring some use cases to the local 351 label field? Or maybe such dichotomy using local label and global 352 label does not exist. 354 5. IANA Considerations 356 This document makes no request of IANA. 358 6. Security Considerations 360 TBD. 362 7. References 364 7.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, 368 DOI 10.17487/RFC2119, March 1997, 369 . 371 7.2. Informative References 373 [I-D.bryant-mpls-flow-ident] 374 Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 375 Mirsky, "MPLS Flow Identification", draft-bryant-mpls- 376 flow-ident-02 (work in progress), September 2015. 378 [I-D.bryant-mpls-synonymous-flow-labels] 379 Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, 380 M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- 381 bryant-mpls-synonymous-flow-labels-01 (work in progress), 382 July 2015. 384 [I-D.ietf-isis-segment-routing-extensions] 385 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 386 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 387 Extensions for Segment Routing", draft-ietf-isis-segment- 388 routing-extensions-05 (work in progress), June 2015. 390 [I-D.ietf-ospf-segment-routing-extensions] 391 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 392 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 393 Extensions for Segment Routing", draft-ietf-ospf-segment- 394 routing-extensions-05 (work in progress), June 2015. 396 [I-D.ietf-spring-segment-routing] 397 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 398 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 399 ietf-spring-segment-routing-06 (work in progress), October 400 2015. 402 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 403 Label Switching Architecture", RFC 3031, 404 DOI 10.17487/RFC3031, January 2001, 405 . 407 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 408 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 409 . 411 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 412 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 413 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 414 . 416 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 417 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 418 2006, . 420 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 421 LAN Service (VPLS) Using BGP for Auto-Discovery and 422 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 423 . 425 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 426 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 427 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 428 . 430 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 431 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 432 October 2007, . 434 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 435 Label Assignment and Context-Specific Label Space", 436 RFC 5331, DOI 10.17487/RFC5331, August 2008, 437 . 439 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 440 Regan, J., and S. Amante, "Flow-Aware Transport of 441 Pseudowires over an MPLS Packet Switched Network", 442 RFC 6391, DOI 10.17487/RFC6391, November 2011, 443 . 445 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 446 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 447 2012, . 449 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 450 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 451 RFC 6790, DOI 10.17487/RFC6790, November 2012, 452 . 454 [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and 455 C. Kodeboniya, "Multicast in Virtual Private LAN Service 456 (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, 457 . 459 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 460 and Retiring Special-Purpose MPLS Labels", RFC 7274, 461 DOI 10.17487/RFC7274, June 2014, 462 . 464 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 465 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 466 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 467 2015, . 469 Authors' Addresses 471 Zhenbin Li 472 Huawei Technologies 473 Huawei Bld., No.156 Beiqing Rd. 474 Beijing 100095 475 China 477 Email: lizhenbin@huawei.com 479 Quintin Zhao 480 Huawei Technologies 481 125 Nagog Technology Park 482 Acton, MA 01719 483 US 485 Email: quintin.zhao@huawei.com 487 Tianle Yang 488 China Mobile 489 32, Xuanwumenxi Ave. 490 Beijing 01719 491 China 493 Email: yangtianle@chinamobile.com 495 Robert Raszuk 496 Individual 498 Email: robert@raszuk.net 500 Luyuan Fang 501 Microsoft 502 5600 148th Ave NE 503 Redmond, WA 98052 504 USA 506 Email: lufang@microsoft.com