idnits 2.17.1 draft-ietf-l2vpn-vpls-pe-etree-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 : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 886 has weird spacing: '...) where any t...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Ethernet-Tree (E-Tree) service is defined in Metro Ethernet Forum (MEF) as a Rooted-Multipoint Ethernet Virtual Connection (EVC) service. It is a multipoint Ethernet service with special restrictions: the frames from a root may be received by any other root or leaf, and the frames from a leaf may be received by any root, but MUST not be received by a leaf. Further, an E-Tree service may include multiple roots and multiple leaves. Although VPMS or P2MP multicast is a somewhat simplified version of this service, in fact, there is no exact corresponding terminology in IETF. -- The document date (April 8, 2014) is 3669 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Etree-req' is mentioned on line 207, but not defined == Missing Reference: 'Vpls-etree' is mentioned on line 152, but not defined == Missing Reference: 'Etree-2PW' is mentioned on line 158, but not defined == Unused Reference: 'ETree-req' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'ETree-frwk' is defined on line 861, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Downref: Normative reference to an Informational RFC: RFC 6136 == Outdated reference: A later version (-10) exists of draft-ietf-l2vpn-etree-frwk-04 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Working Group Y. Jiang 2 L. Yong 3 Internet Draft Huawei 5 Intended status: Standards Track M. Paul 6 Deutsche Telekom 8 F. Jounay 9 Orange CH 11 F. Balus 12 W. Henderickx 13 Alcatel-Lucent 15 A. Sajassi 16 Cisco 18 Expires: October 2014 April 8, 2014 20 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) 21 draft-ietf-l2vpn-vpls-pe-etree-03.txt 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on October 8, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Abstract 62 A generic Virtual Private LAN Service (VPLS) solution is proposed for 63 Ethernet-Tree (E-Tree) services which uses VLANs to indicate root or 64 leaf traffic. A VPLS Provider Edge (PE) model is illustrated as an 65 example for the solution. In the solution, E-Tree VPLS PEs are 66 interconnected by PWs which carry the VLAN indicating the E-Tree 67 attribute, the MAC address based Ethernet forwarding engine and the 68 PW work in the same way as before. A signaling mechanism for E-Tree 69 capability and VLAN mapping negotiation is further described. 71 Table of Contents 73 1. Conventions used in this document ......................... 3 74 2. Terminology ............................................... 3 75 3. Introduction .............................................. 4 76 4. PE Model with E-Tree Support .............................. 5 77 4.1. Existing PE Models ..................................... 5 78 4.2. A New PE Model with E-Tree Support ..................... 8 79 5. PW for E-Tree Support ..................................... 9 80 5.1. PW Encapsulation ....................................... 9 81 5.2. VLAN Mapping ........................................... 9 82 5.3. PW Processing ......................................... 11 83 5.3.1. PW Processing in the VLAN Mapping Mode .......... 11 84 5.3.2. PW Processing in the Compatible Mode ............ 12 85 5.3.3. PW Processing in the Optimized Mode ............. 13 86 6. Signaling for E-Tree Support ............................. 14 87 6.1. LDP Extensions for E-Tree Support ..................... 14 88 6.2. BGP Extensions for E-Tree Support ..................... 16 89 7. OAM Considerations ....................................... 18 90 8. Applicability ............................................ 18 91 9. Security Considerations .................................. 18 92 10. IANA Considerations ...................................... 19 93 11. References ............................................... 19 94 11.1. Normative References ............................... 19 95 11.2. Informative References ............................. 20 96 12. Acknowledgments .......................................... 20 97 Appendix A. Other PE Models for E-Tree ........................ 21 98 A.1. A PE Model With a VSI and No bridge ................... 21 99 A.2. A PE Model With external E-Tree interface ............. 22 101 1. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. Terminology 109 E-Tree: Ethernet Tree, a Rooted-Multipoint EVC service as defined in 110 MEF 6.1 112 EVC: Ethernet Virtual Connection, as defined in MEF 4.0 114 FIB: Forwarding Information Base, or forwarding table 116 T-VSI: Tree VSI, a VSI with E-Tree support 118 Root AC, an AC attached with a root 120 Leaf AC, an AC attached with a leaf 122 C-VLAN, Customer VLAN 124 S-VLAN, Service VLAN 126 B-VLAN, Backbone VLAN 128 Root VLAN, a VLAN ID used to indicate all the frames that are 129 originated at a root AC 131 Leaf VLAN, a VLAN ID used to indicate all the frames that are 132 originated at a leaf AC 134 I-SID, Backbone Service Instance Identifier, as defined in IEEE 135 802.1ah 137 3. Introduction 139 The Ethernet-Tree (E-Tree) service is defined in Metro Ethernet Forum 140 (MEF) as a Rooted-Multipoint Ethernet Virtual Connection (EVC) 141 service. It is a multipoint Ethernet service with special 142 restrictions: the frames from a root may be received by any other 143 root or leaf, and the frames from a leaf may be received by any root, 144 but MUST not be received by a leaf. Further, an E-Tree service may 145 include multiple roots and multiple leaves. Although VPMS or P2MP 146 multicast is a somewhat simplified version of this service, in fact, 147 there is no exact corresponding terminology in IETF. 149 [Etree-req] gives the requirements for providing E-Tree solutions in 150 the VPLS and the need to filter leaf-to-leaf traffic. 152 [Vpls-etree] describes a PW control word based E-Tree solution, where 153 a bit in the PW control word is used to indicate the root/leaf 154 attribute for a packet. The Ethernet forwarder in the VPLS is also 155 extended to filter the leaf-to-leaf traffic based on the tuple. 158 [Etree-2PW] proposes another E-Tree solution where root and leaf 159 traffic are classified and forwarded in the same VSI but with two 160 separate PWs. 162 Both solutions are only applicable to "VPLS only" networks. 164 In fact, VPLS PE usually consists of a bridge module itself (see 165 [RFC4664] and [RFC6246]); moreover, E-Tree services may cross both 166 Ethernet and VPLS domains. Therefore, it is necessary to develop an 167 E-Tree solution both for "VPLS only" scenarios and for interworking 168 between Ethernet and VPLS. 170 IEEE 802.1 has incorporated the generic E-Tree solution in the latest 171 version of 802.1Q [802.1Q-2011], which is just an improvement on the 172 traditional asymmetric VLAN mechanism (the use of different VLANs to 173 indicate E-Tree root/leaf attributes and prohibiting leaf-to-leaf 174 traffic with the help of VLANs was first standardized in IEEE 802.1Q- 175 2003). In the solution, VLANs are used to indicate root/leaf 176 attribute of a packet: one VLAN ID is used to indicate the frames 177 originated from the roots and another VLAN ID is used to indicate the 178 frames originated from the leaves. At a leaf port, the bridge can 179 then filter out all the frames from other leaf ports based on the 180 VLAN ID. It is better to reuse the same mechanism in VPLS than to 181 develop a new mechanism. The latter will introduce more complexity to 182 interwork with IEEE 802.1Q solution. 184 This document introduces how the Ethernet VLAN solution can be used 185 to support generic E-Tree services in VPLS. The solution proposed 186 here is fully compatible with the IEEE bridge architecture and the 187 IETF PWE3 technology, thus it will not change the FIB (such as 188 installing E-Tree attributes in the FIB), or need any specially 189 tailored implementation. Furthermore, VPLS scalability and simplicity 190 is also well kept. With this mechanism, it is also convenient to 191 deploy a converged E-Tree service across both Ethernet and MPLS 192 networks. 194 Firstly, a typical VPLS PE model is introduced as an example; the 195 model is then extended in which a Tree VSI is connected to a VLAN 196 bridge with a dual-VLAN interface. 198 This document then discusses the PW encapsulation and PW processing 199 such as VLAN mapping options for transporting E-Tree services in 200 VPLS. 202 Finally, it describes the signaling extensions and processing 203 procedures for E-Tree support in VPLS. 205 4. PE Model with E-Tree Support 207 Problem scenario of E-Tree as shown in Fig. 1 of [Etree-req] is a 208 simplification of the L2VPN architecture, several common VPLS PE 209 architectures are discussed in more details in [RFC4664] and 210 [RFC6246]. 212 Therefore, E-Tree solution in VPLS is demonstrated with the help of a 213 typical VPLS PE model. It can also be used by other PE models which 214 are discussed in Appendix A. 216 4.1. Existing PE Models 218 According to [RFC4664], there are at least three models possible for 219 a VPLS PE, including: 221 o A single bridge module, a single VSI; 223 o A single bridge module, multiple VSIs; 225 o Multiple bridge modules, each attaches to a VSI. 227 The second PE model is commonly used. A typical example is further 228 depicted in Fig. 1 and Fig. 2 [RFC6246], where an S-VLAN bridge 229 module is connected to multiple VSIs each with a single VLAN virtual 230 interface. 232 +-------------------------------+ 233 | 802.1ad Bridge Module Model | 234 | | 235 +---+ | +------+ +-----------+ | 236 |CE |---------|C-VLAN|------| | | 237 +---+ | |bridge|------| | | 238 | +------+ | | | 239 | o | S-VLAN | | 240 | o | | | 241 | o | Bridge | | 242 +---+ | +------+ | | | 243 |CE |---------|C-VLAN|------| | | 244 +---+ | |bridge|------| | | 245 | +------+ +-----------+ | 246 +-------------------------------+ 248 Figure 1 A model of 802.1ad Bridge Module 250 +----------------------------------------+ 251 | VPLS-capable PE model | 252 | +---------------+ +------+ | 253 | | | |VSI-1 |------------ 254 | | |==========| |------------ PWs 255 | | Bridge ------------ |------------ 256 | | | S-VLAN-1 +------+ | 257 | | Module | o | 258 | | | o | 259 | | (802.1ad | o | 260 | | bridge) | o | 261 | | | o | 262 | | | S-VLAN-n +------+ | 263 | | ------------VSI-n |------------- 264 | | |==========| |------------- PWs 265 | | | ^ | |------------- 266 | +---------------+ | +------+ | 267 | | | 268 +-------------------------|--------------+ 269 LAN emulation Interface 271 Figure 2 A VPLS-capable PE Model 273 In this PE model, Ethernet frames from Customer Edges (CEs) will 274 cross multiple stages of bridge modules (i.e., C-VLAN and S-VLAN 275 bridge) and a VSI in a PE before being sent on the PW to a remote PE. 276 Therefore, the association between an AC port and a PW on a VSI is 277 difficult, sometimes even impossible. 279 This model could be further enhanced: When Ethernet frames arrive at 280 a PE, a root VLAN or a leaf VLAN tag is added. Then the frames with 281 the root VLAN tag are transmitted both to the roots and the leaves, 282 while the frames with the leaf VLAN tag are transmitted to the roots 283 but dropped for the leaves (these VLAN tags are removed before the 284 frames are transmitted over the wire). It was demonstrated in 285 [802.1Q-2011] that the E-Tree service in Ethernet networks can be 286 well supported with this mechanism. 288 Assuming this mechanism is implemented in the bridge module, it is 289 quite straightforward to infer a VPLS PE model with two VSIs to 290 support the E-Tree (as shown in Fig. 3). But this model will require 291 two VSIs per PE and two sets of PWs per E-Tree service, which is 292 poorly scalable in a large MPLS/VPLS network; in addition, both these 293 VSIs have to share their learned MAC addresses. 295 +----------------------------------------+ 296 | VPLS-capable PE model | 297 | +---------------+ +------+ | 298 | | | |VSI-1 |------------ 299 | | |==========| |------------ PWs 300 | | Bridge ------------ |------------ 301 | | | Root +------+ | 302 | | Module | S-VLAN | 303 | | | | 304 | | (802.1ad | | 305 | | bridge) | | 306 | | | Leaf | 307 | | | S-VLAN +------+ | 308 | | ------------VSI-2 |------------- 309 | | |==========| |------------- PWs 310 | | | ^ | |------------- 311 | +---------------+ | +------+ | 312 | | | 313 +-------------------------|--------------+ 314 LAN emulation Interface 316 Figure 3 A VPLS PE Model for E-Tree with 2 VSIs 318 4.2. A New PE Model with E-Tree Support 320 In order to support the E-Tree in a more scalable way, a new VPLS PE 321 model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is 322 proposed. As depicted in Fig. 4, the bridge module is connected to 323 the T-VSI with a dual-VLAN virtual interface, i.e., both the root 324 VLAN and the leaf VLAN are connected to the same T-VSI, and they 325 share the same FIB and work in shared VLAN learning. In this way, 326 only one VPLS instance and one set of PWs is needed per E-Tree 327 service, and the scalability of VPLS is improved. 329 +----------------------------------------+ 330 | VPLS-capable PE model | 331 | +---------------+ +------+ | 332 | | |==========|TVSI-1|------------ 333 +---+AC | | ------------ |------------ PWs 334 |CE |-------| Bridge ------------ |------------ 335 +---+ | | | Root & +------+ | 336 | | Module | Leaf VLAN o | 337 | | | o | 338 | | | o | 339 | | | o | 340 | | | o | 341 +---+AC | | | VLAN-n +------+ | 342 |CE |-------| ------------VSI-n |------------- 343 +---+ | | |==========| |------------- PWs 344 | | | ^ | |------------- 345 | +---------------+ | +------+ | 346 | | | 347 +-------------------------|--------------+ 348 LAN emulation Interface 350 Figure 4 A VPLS PE Model for E-Tree with a Single T-VSI 352 For an untagged port (frames over this port are untagged) or VLAN- 353 unaware port (VLAN tags in the frames are ignored), the Ethernet 354 frames received from the root ACs SHOULD be tagged with a root C-VLAN, 355 and optionally MAY be added with another root S-VLAN. 357 For a C-VLAN tagged port, the Ethernet frames received from the root 358 ACs SHOULD be added with a root S-VLAN. 360 For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames 361 received from the root ACs SHOULD be translated to the root S-VLAN in 362 the VPLS network domain. Alternatively, the PBB VPLS PE model (where 363 an IEEE 802.1ah bridge module is embedded in the PE) as described in 364 [PBB-VPLS] MAY be used, and a root B-VLAN or leaf B-VLAN MAY be added 365 in this case (the E-Tree attribute may also be indicated with two I- 366 SID tags in the bridge module, and the frames are further 367 encapsulated and transported transparently over a single B-VLAN, thus 368 the PBB VPLS works just in the same way as described in [PBB-VPLS] 369 and will be discussed no more in this document). When many S-VLANs 370 are multiplexed in a single AC, the 2nd option has an advantage of 371 both VLAN scalability and MAC address scalability. 373 In a similar way, the traffic from the leaf ACs is tagged and 374 transported on the leaf C-VLAN, S-VLAN or B-VLAN. 376 In all cases, the outermost VLAN in the resulted Ethernet header is 377 used to indicate the E-Tree attribute of an Ethernet frame; this 378 document will use VLAN to refer to this outermost VLAN for simplicity 379 in the latter sections. 381 5. PW for E-Tree Support 383 5.1. PW Encapsulation 385 To support an E-Tree service, T-VSIs in a VPLS must be interconnected 386 with a bidirectional Ethernet PW. The Ethernet PW may work in the 387 tagged mode (PW type 0x0004) as described in [RFC4448], and a VLAN 388 tag must be carried in each frame in the PW to indicate the frame 389 originated from either root or leaf (the VLAN tag indicating the 390 frame originated from either root or leaf can be translated by a 391 bridge module in the PE or added by an outside Ethernet edge device, 392 even by a customer device). In the tagged PW mode, two service 393 delimiting VLANs must be allocated in the VPLS domain for an E-Tree. 394 PW processing for the tagged PW will be described in Section 5.3 of 395 this document. 397 Raw PW (PW type 0x0005 in [RFC4448]) may be used to carry E-Tree 398 service for a PW in Compatible mode as shown in Section 5.3.2. 400 5.2. VLAN Mapping 402 There are two ways of manipulating VLANs for an E-Tree in VPLS: 404 o Global VLAN based, that is, provisioning two global VLANs (Root 405 VLAN, Leaf VLAN) across the VPLS network, thus no VLAN mapping is 406 needed at all, or the VLAN mapping is done completely in the 407 Ethernet domains. 409 o Local VLAN based, that is, provisioning two local VLANs for each 410 PE (which participates in the E-Tree) in the VPLS network 411 independently. 413 The first method requires no VLAN mapping in the PW, but two unique 414 service delimiting VLANs must be allocated across the VPLS domain. 416 The second method is more scalable in the use of VLANs, but needs a 417 VLAN mapping mechanism in the PW similar to what is already described 418 in Section 4.3 of [RFC4448]. 420 Global or local VLANs can be manually configured or provisioned by an 421 OSS system. Alternatively, some automatic VLAN allocation algorithm 422 may be provided in the management plane, but it is out scope of this 423 document. 425 For both methods, VLAN mapping parameters from a remote PE can be 426 provisioned or determined by a signaling protocol as described in 427 Section 6 when a PW is being established. 429 5.3. PW Processing 431 5.3.1.PW Processing in the VLAN Mapping Mode 433 In the VLAN Mapping mode, two VPLS PEs with E-Tree capability are 434 inter-connected with a PW (For example, the scenario of Fig. 5 435 depicts the interconnection of two PEs miscellaneously attached with 436 both root and leaf nodes). 438 +------------------------+ 439 | VPLS PE with T-VSI | 440 | | 441 +----+ | +------+ +-----+ | PW 442 |Root|------| VLAN |-------|T-VSI|---------- 443 +----+ | | BRG | | |---------- 444 +----+ | | |-------| |---------- 445 |Leaf|------| | | |---------+ 446 +----+ | +------+ +-----+ | | 447 | | | 448 +------------------------+ | 449 | 450 +------------------------+ | 451 | VPLS PE with T-VSI | | 452 | | | 453 +----+ | +------+ +-----+ | PW | 454 |Root|------| VLAN |-------|T-VSI|---------+ 455 +----+ | | BRG | | |---------- 456 +----+ | | |-------| |---------- 457 |Leaf|------| | | |---------- 458 +----+ | +------+ +-----+ | 459 | | 460 +------------------------+ 462 Figure 5 T-VSI Interconnected in the Normal Mode 464 If a PE is in the VLAN mapping mode for a PW, then in the data plane 465 the PE MUST map the VLAN in each frame as follows: 467 o Upon transmitting frames on the PW, map from local VLAN to remote 468 VLAN (i.e., the local leaf VLAN in a frame is translated to the 469 remote leaf VLAN; the local root VLAN in a frame is translated to the 470 remote root VLAN). 472 o Upon receiving frames on the PW, map from remote VLAN to local VLAN, 473 and the frames are further forwarded or dropped in the egress bridge 474 module using the filtering mechanism as described in [802.1Q-2011]. 476 The signaling for VLANs is specified in Section 6. 478 5.3.2.PW Processing in the Compatible Mode 480 The new VPLS PE model can work in a traditional VPLS network 481 seamlessly in the compatibility mode. As shown in Fig. 6, the VPLS PE 482 with T-VSI can be attached with root and/or leaf nodes, while the 483 VPLS PE with a traditional VSI can only be attached with root nodes. 484 A raw PW should be used to connect them. 486 +------------------------+ 487 | VPLS PE with T-VSI | 488 | | 489 +----+ | +------+ +-----+ | PW 490 |Root|------| VLAN |-------|T-VSI|---------- 491 +----+ | | BRG | | |---------- 492 +----+ | | |-------| |---------- 493 |Leaf|------| | | |---------+ 494 +----+ | +------+ +-----+ | | 495 | | | 496 +------------------------+ | 497 | 498 +------------------------+ | 499 | VPLS PE with VSI | | 500 | | | 501 +----+ | +------+ +-----+ | PW | 502 |Root|------| VLAN |-------|VSI |---------+ 503 +----+ | | BRG | | |---------- 504 +----+ | | | | |---------- 505 |Root|------| | | |---------- 506 +----+ | +------+ +-----+ | 507 | | 508 +------------------------+ 510 Figure 6 T-VSI interconnected with Traditional VSI 512 If a PE is in the Compatible mode for a PW, then in the data plane 513 the PE MUST process the frame as follows: 515 o Upon transmitting frames on the PW, remove the root or leaf VLAN in 516 the frames. 518 o Upon receiving frames on the PW, add a VLAN tag with a value of the 519 local root VLAN to the frames. 521 5.3.3.PW Processing in the Optimized Mode 523 When two PEs (both have E-Tree capability) are inter-connected and 524 one of them (e.g., PE2) is attached with only leaf nodes, as shown in 525 the scenario of Fig. 7, its peer PE (e.g., PE1) should then work in 526 the optimized mode. In this case, PE1 should not send the frames 527 originated from the local leaf VLAN to PE2, i.e., these frames are 528 dropped rather than transported over the PW. The bandwidth efficiency 529 of the VPLS can thus be improved. The signaling for the PE attached 530 with only leaf nodes is specified in Section 6. 531 +------------------------+ 532 |VPLS PE with T-VSI (PE1)| 533 | | 534 +----+ | +------+ +-----+ | PW 535 |Root|------| VLAN |-------|T-VSI|---------- 536 +----+ | | BRG | | |---------- 537 +----+ | | |-------| |---------- 538 |Leaf|------| | | |---------+ 539 +----+ | +------+ +-----+ | | 540 | | | 541 +------------------------+ | 542 | 543 +------------------------+ | 544 |VPLS PE with T-VSI (PE2)| | 545 | | | 546 +----+ | +------+ +-----+ | PW | 547 |Leaf|------| VLAN |-------|T-VSI|---------+ 548 +----+ | | BRG | | |---------- 549 +----+ | | |-------| |---------- 550 |Leaf|------| | | |---------- 551 +----+ | +------+ +-----+ | 552 | | 553 +------------------------+ 555 Figure 7 T-VSI interconnected with PE attached with only leaf nodes 557 If a PE is in the Optimized Mode for a PW, upon transmit, the PE 558 SHOULD first operate as follows: 560 o Drop a frame if its VLAN ID matches the local leaf VLAN ID. 562 6. Signaling for E-Tree Support 564 6.1. LDP Extensions for E-Tree Support 566 In addition to the signaling procedures as specified in [RFC4447], 567 this document proposes a new interface parameter sub-TLV to provision 568 an E-Tree service and negotiate the VLAN mapping function, as follows: 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | E-Tree | Length=8 | Reserved |P|V| 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Root VLAN ID | Leaf VLAN ID | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Figure 8 E-Tree Sub-TLV 579 Where: 581 o E-Tree is the sub-TLV identifier to be assigned by IANA. 583 o Length is the length of the sub TLV in octets. 585 o Reserved bits MUST be set to zero on transmit and be ignored on 586 receive. 588 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 589 attached with only leaf nodes, and set to 0 otherwise. 591 o V is a bit indicating the sender's VLAN mapping capability. A PE 592 capable of VLAN mapping MUST set this bit, and clear it otherwise. 594 o Root VLAN ID is the value of the local root VLAN. 596 o Leaf VLAN ID is the value of the local leaf VLAN. 598 When setting up a PW for the E-Tree based VPLS, two PEs negotiate the 599 E-Tree support using the above E-Tree sub-TLV. Note PW type of 0x0004 600 should be used during the PW negotiation. 602 A PE that wishes to support E-Tree service MUST include an E-Tree 603 Sub-TLV in its PW label mapping message and include its local root 604 VLAN ID and leaf VLAN ID in the TLV. A PE that has the VLAN mapping 605 capability MUST set the V bit to 1, and a PE is attached with only 606 leaf nodes SHOULD set the P bit to 1. 608 In default, for each PW, VLAN-Mapping-Mode, Compatible-Mode, and 609 Optimized-Mode are all set to FALSE. 611 A PE that receives a PW label mapping message with an E-Tree Sub-TLV 612 from its peer PE, after saving the VLAN information for the PW, must 613 process it as follows: 615 1) if the root and leaf VLAN ID in the message match the local root 616 and leaf VLAN ID, then continue to 3); 618 2) else { 620 if the bit V is cleared, then { 622 if the PE is capable of VLAN mapping, then it MUST set 623 VLAN-Mapping-Mode to TRUE; 625 else { 627 A label release message with the error code "E-Tree 628 VLAN mapping not supported" is sent to the peer PE 629 and exit the process; 631 } 633 } 635 if the bit V is set, and the PE is capable of VLAN mapping, 636 then the PE with the minimum IP address MUST set VLAN-Mapping- 637 Mode to TRUE; 639 } 641 3) If the P bit is set, then: 643 { 645 If the PE is a leaf-only node itself, then a label release 646 message with a status code "Leaf to Leaf PW released" is sent to 647 the peer PE and exit the process; 649 Else the PE SHOULD set the Optimized-Mode to TRUE. 651 } 653 If a PE has sent an E-Tree Sub-TLV but does not receive any E-Tree 654 Sub-TLV in its peer's PW label mapping message, The PE SHOULD then 655 establish a raw PW with this peer as in traditional VPLS and set 656 Compatible-Mode to TRUE for this PW. 658 Data plane processing for this PW is as following: 660 If Optimized-Mode is TRUE, then data plane processing as described in 661 Section 5.3.3 applies. 663 If VLAN-Mapping-Mode is TRUE, then data plane processing as described 664 in Section 5.3.1 applies. 666 If Compatible-Mode is TRUE, then data plane processing is as 667 described in Section 5.3.2. 669 PW processing as described in [RFC4448] proceeds as usual for all 670 cases. 672 6.2. BGP Extensions for E-Tree Support 674 A new E-Tree extended community is proposed for E-Tree signaling in 675 BGP VPLS: 677 +------------------------------------+ 678 | Extended community type (2 octets) | 679 +------------------------------------+ 680 | Root VLAN (2 octets) | 681 +------------------------------------+ 682 | Leaf VLAN (2 octets) | 683 +------------------------------------+ 684 | Reserved |P|V| 685 +------------------------------------+ 687 Figure 9 E-Tree Extended Community 689 Where: 691 o Root VLAN ID is the value of the local root VLAN. 693 o Leaf VLAN ID is the value of the local leaf VLAN. 695 o Reserved, 14 bits MUST be set to zero on transmit and be ignored 696 on receive. 698 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 699 attached with only leaf nodes, and set to 0 otherwise. 701 o V is a bit indicating the sender's VLAN mapping capability. A PE 702 capable of VLAN mapping MUST set this bit, and clear it otherwise. 704 The PEs attached with both leaf and root nodes MUST support BGP E- 705 Tree signaling as described in this document, and SHOULD support VLAN 706 mapping in their data planes. The traditional PE attached with only 707 root nodes may also participate in an E-Tree service. If some PEs 708 don't support VLAN mapping, global VLANs as per Section 5.2 MUST be 709 provisioned for an E-Tree service. 711 In BGP VPLS signaling, besides attaching a Layer2 Info Extended 712 Community as detailed in [RFC4761], an E-Tree Extended Community MUST 713 be further attached if a PE wishes to participate in an E-Tree 714 service. The PE MUST include its local root VLAN ID and leaf VLAN ID 715 in the E-Tree Extended Community. A PE attached with only leaf nodes 716 of an E-Tree SHOULD set the P bit in the E-Tree Extended Community to 717 1. 719 A PE that receives a BGP UPDATE message with an E-Tree Extended 720 Community from its peer PE, after saving the VLAN information for the 721 PW, must process it as follows (after processing procedures as 722 specified in Section 3.2 of [RFC4761]): 724 1) if the root and leaf VLAN ID in the E-Tree Extended Community 725 match the local root and leaf VLAN ID, then continue to 3); 727 2) else { 729 if the bit V is cleared, then { 731 if the PE is capable of VLAN mapping, then it MUST set 732 VLAN-Mapping-Mode to TRUE; 734 else { 736 Log with a message "E-Tree VLAN mapping not 737 supported" and exit the process; 739 } 741 if the bit V is set, and the PE is capable of VLAN mapping, 742 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 743 to TRUE; 745 } 747 3) If the P bit is set { 748 If the PE is a leaf-only PE itself, then forbids any traffic on 749 the PW; 751 Else the PE SHOULD set the Optimized-Mode to TRUE. 753 } 755 A PE which does not recognize this attribute shall ignore it silently. 756 If a PE has sent an E-Tree Extended Community but does not receive 757 any E-Tree Extended Community from its peer, the PE SHOULD then 758 establish a raw PW with this peer as in traditional VPLS, and set 759 Compatible-Mode to TRUE for this PW. 761 Data plane in the VPLS is the same as described in Section 4.2 of 762 [RFC4761], and data plane processing for a PW is the same as 763 described at the end of Section 6.1. 765 7. OAM Considerations 767 VPLS OAM requirements and framework as specified in [RFC6136] are 768 applicable to E-Tree, as both Ethernet OAM frames and data traffic 769 are transported over the same PW. 771 Ethernet OAM for E-Tree including both service OAM and segment OAM 772 frames shall undergo the same VLAN mapping as the data traffic; and 773 root VLAN SHOULD be applied to segment OAM frames so that they are 774 not filtered. 776 8. Applicability 778 The solution is applicable to both LDP VPLS [RFC4762] and BGP VPLS 779 [RFC4761]. 781 The solution is applicable to both "VPLS Only" networks and VPLS with 782 Ethernet aggregation networks. 784 The solution is also applicable to PBB VPLS networks. 786 9. Security Considerations 788 Besides security considerations as described in [RFC4448], [RFC4761] 789 and [RFC4762], this solution prevents leaf to leaf communication in 790 the data plane of VPLS when its PEs are interconnected with PWs. In 791 this regard, security can be enhanced for customers with this 792 solution. 794 10. IANA Considerations 796 IANA is requested to allocate a value for E-Tree in the registry of 797 Pseudowire Interface Parameters Sub-TLV type. 799 Parameter ID Length Description 800 ======================================= 801 TBD 8 E-Tree 803 IANA is requested to allocate two new LDP status codes from the 804 registry of name "STATUS CODE NAME SPACE". The following values are 805 suggested: 807 Range/Value E Description 808 ------------- ----- ---------------------- 809 TBD 1 E-Tree VLAN mapping not supported 810 TBD 0 Leaf to Leaf PW released 812 IANA is requested to allocate a value for E-Tree in the registry of 813 BGP Extended Community. 815 Type Value Name 816 ======================================= 817 TBD E-Tree Info 819 11. References 821 11.1. Normative References 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, March 1997. 826 [RFC4447] Martini, L., and et al, "Pseudowire Setup and Maintenance 827 Using Label Distribution Protocol (LDP)", RFC 4447, April 828 2006. 830 [RFC4448] Martini, L., and et al, "Encapsulation Methods for 831 Transport of Ethernet over MPLS Networks", RFC 4448, April 832 2006. 834 [RFC4761] Kompella, K. and Rekhter, Y., "Virtual Private LAN Service 835 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 836 4761, January 2007 838 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN 839 Services using LDP", RFC 4762, January 2007. 841 [RFC6136] Sajassi, A. and Mohan, D., "L2VPN OAM Requirements and 842 Framework", RFC 6136, March 2011 844 11.2. Informative References 846 [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to- 847 Edge (PWE3) Architecture", RFC 3985, March 2005. 849 [RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2 850 Virtual Private Networks (L2VPNs)", RFC 4664, September 851 2006. 853 [RFC6246] Sajassi, A., and et al, "Virtual Private LAN Service (VPLS) 854 Interoperability with Customer Edge (CE) Bridges", RFC 6246, 855 June 2011 857 [ETree-req] Key, R., et al, "Requirements for Metro Ethernet Forum 858 (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual 859 Private Network (L2VPN)", RFC 7152, March 2014 861 [ETree-frwk] Key, R., and et al, "A Framework for E-Tree Service over 862 MPLS Network", draft-ietf-l2vpn-etree-frwk-04, Work in 863 Progress 865 [802.1Q-2011] IEEE 802.1Q, Media Access Control (MAC) Bridges and 866 Virtual Bridge Local Area Networks, August 2011 868 [PBB-VPLS] Balus, F., and et al., Extensions to VPLS PE model for 869 Provider Backbone Bridging, draft-ietf-l2vpn-pbb-vpls-pe- 870 model-07, Work in Progress 872 12. Acknowledgments 874 The authors would like to thank Adrian Farrel, Susan Hares and Shane 875 Amante for their valuable advices, thank Ben Mack-crane, Edwin 876 Mallette, Donald Fedyk, Dave Allan, Giles Heron, Raymond Key, Josh 877 Rogers, Sam Cao and Daniel Cohn for their valuable comments and 878 discussions. 880 Appendix A. Other PE Models for E-Tree 882 A.1. A PE Model With a VSI and No bridge 884 If there is no bridge module in a PE, the PE may consist of Native 885 Service Processors (NSPs) as shown in Figure A.1 (adapted from Fig. 5 886 of [RFC3985]) where any transformation operation for VLANs (e.g., 887 VLAN insertion/removal or VLAN mapping) may be applied. Thus a root 888 VLAN or leaf VLAN can be added by the NSP depending on the UNI type 889 (root/leaf) associated with the AC over which the packet arrives. 891 Further, when a packet with a leaf VLAN exits a forwarder and arrives 892 at the NSP, the NSP must drop the packet if the egress AC is 893 associated with a leaf UNI. 895 Tagged PW and VLAN mapping work in the same way as in the typical PE 896 model. 898 +----------------------------------------+ 899 | PE Device | 900 Multiple+----------------------------------------+ 901 AC | | | Single | PW Instance 902 <------>o NSP # + PW Instance X<----------> 903 | | | | 904 |------| VSI |----------------------| 905 | | | Single | PW Instance 906 <------>o NSP #Forwarder + PW Instance X<----------> 907 | | | | 908 |------| |----------------------| 909 | | | Single | PW Instance 910 <------>o NSP # + PW Instance X<----------> 911 | | | | 912 +----------------------------------------+ 914 Figure A.1 A PE model with a VSI and no bridge module 916 This PE model may be used by an MTU-s in an H-VPLS network, or an N- 917 PE in an H-VPLS network with non-bridging edge devices, wherein a 918 spoke PW can be treated as an AC in this model. 920 A.2. A PE Model With external E-Tree interface 922 +----------------------------------------+ 923 | PE Device | 924 Root +----------------------------------------+ 925 VLAN | | Single | PW Instance 926 <------>o + PW Instance X<----------> 927 | | | 928 | VSI |----------------------| 929 | | Single | PW Instance 930 | Forwarder + PW Instance X<----------> 931 | | | 932 Leaf | |----------------------| 933 VLAN | | Single | PW Instance 934 <------>o + PW Instance X<----------> 935 | | | 936 +----------------------------------------+ 938 Figure A.2 A PE model with external E-Tree interface 940 A more simplified PE model is depicted in A.2, where Root/Leaf VLANs 941 are directly or indirectly over a single PW connected to a same VSI 942 forwarder in a PE, any transformation of E-Tree VLANs, e.g., VLAN 943 insertion/removal or VLAN mapping, can be performed by some outer 944 equipments, and the PE may further translate these VLANs into its own 945 local VLANs. This PE model may be used by an N-PE in an H-VPLS 946 network with bridging-capable devices, or scenarios such as providing 947 E-Tree Network-to-Network (NNI) interfaces. 949 Authors' Addresses 951 Yuanlong Jiang 952 Huawei Technologies Co., Ltd. 953 Bantian, Longgang district 954 Shenzhen 518129, China 955 Email: jiangyuanlong@huawei.com 957 Lucy Yong 958 Huawei USA 959 207 Estrella Xing 960 Georgetown TX, USA 78628 961 Email: lucyyong@huawei.com 963 Manuel Paul 964 Deutsche Telekom 965 Winterfeldtstr. 21 966 10781 Berlin, Germany 967 Email: manuel.paul@telekom.de 969 Frederic Jounay 970 Orange CH 971 4 rue caudray 1020 Renens, Switzerland 972 Email: frederic.jounay@orange.ch 974 Florin Balus 975 Alcatel-Lucent 976 701 E. Middlefield Road 977 Mountain View, CA, USA 94043 978 Email: florin.balus@alcatel-lucent.com 980 Wim Henderickx 981 Alcatel-Lucent 982 Copernicuslaan 50 983 2018 Antwerp, Belgium 984 Email: wim.henderickx@alcatel-lucent.com 986 Ali Sajassi 987 Cisco 988 170 West Tasman Drive 989 San Jose, CA 95134, USA 990 Email: sajassi@cisco.com