idnits 2.17.1 draft-ietf-l2vpn-vpls-pe-etree-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 : ---------------------------------------------------------------------------- ** There are 8 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 657 has weird spacing: '...cessing as...' == Line 858 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 E-Tree service is defined in Metro Ethernet Forum (MEF) as a Rooted-Multipoint 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 (September 12, 2012) is 4237 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 203, but not defined == Unused Reference: 'ETree-req' is defined on line 827, 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 (-05) exists of draft-ietf-l2vpn-etree-reqt-01 == Outdated reference: A later version (-07) exists of draft-key-l2vpn-vpls-etree-06 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-pbb-vpls-pe-model-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: March 2013 September 12, 2012 20 VPLS PE Model for E-Tree Support 21 draft-ietf-l2vpn-vpls-pe-etree-00.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 March 12, 2013. 45 Copyright Notice 47 Copyright (c) 2012 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 VPLS solution for E-Tree services is proposed which uses 63 VLANs to indicate root/leaf traffic. A VPLS Provider Edge (PE) model 64 is illustrated as an example for the solution. In the solution, E- 65 Tree VPLS PEs are interconnected by PWs which carry the VLAN 66 indicating the E-Tree attribute, the MAC address based Ethernet 67 forwarding engine and the PW work in the same way as before. A 68 signaling mechanism for E-Tree capability and VLAN mapping 69 negotiation is further described. 71 Table of Contents 73 1. Introduction ............................................. 3 74 2. Conventions used in this document ........................ 4 75 3. Terminology .............................................. 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. LDP Extensions for E-Tree Support ....................... 14 87 7. BGP Extensions for E-Tree Support ....................... 16 88 8. OAM Considerations ...................................... 17 89 9. Applicability ........................................... 18 90 10. Security Considerations ................................. 18 91 11. IANA Considerations ..................................... 18 92 12. References .............................................. 19 93 12.1. Normative References .............................. 19 94 12.2. Informative References ............................ 19 95 13. Acknowledgments ......................................... 20 96 Appendix A. Other PE Models for E-Tree ....................... 21 97 A.1. A PE Model With a VSI and No bridge .................. 21 98 A.2. A PE Model With external E-Tree interface ............ 22 100 1. Introduction 102 The E-Tree service is defined in Metro Ethernet Forum (MEF) as a 103 Rooted-Multipoint EVC service. It is a multipoint Ethernet service 104 with special restrictions: the frames from a root may be received by 105 any other root or leaf, and the frames from a leaf may be received by 106 any root, but MUST not be received by a leaf. Further, an E-Tree 107 service may include multiple roots and multiple leaves. Although VPMS 108 or P2MP multicast is a somewhat simplified version of this service, 109 in fact, there is no exact corresponding terminology in IETF. 111 [Etree-req] gives the requirements for providing E-Tree solutions in 112 the VPLS and the need to filter leaf-to-leaf traffic. 114 [Vpls-etree] describes a PW control word based E-Tree solution, where 115 a bit in the PW control word is used to indicate the root/leaf 116 attribute for a packet. The Ethernet forwarder in the VPLS is also 117 extended to filter the leaf-to-leaf traffic based on the tuple. 120 [Etree-2PW] proposes another E-Tree solution where root and leaf 121 traffic are classified and forwarded in the same VSI but with two 122 separate PWs. 124 Both solutions are only applicable to "VPLS only" networks. 126 In fact, VPLS PE usually consists of a bridge module itself (see 127 [RFC4664] and [RFC6246]); moreover, E-Tree services may cross both 128 Ethernet and VPLS domains. Therefore, it is necessary to develop an 129 E-Tree solution both for "VPLS only" scenarios and for interworking 130 between Ethernet and VPLS. 132 IEEE 802.1 has incorporated the generic E-Tree solution in the latest 133 version of 802.1Q [802.1aq], which is just an improvement on the 134 traditional asymmetric VLAN mechanism (the use of different VLANs to 135 indicate E-Tree root/leaf attributes and prohibiting leaf-to-leaf 136 traffic with the help of VLANs was first standardized in IEEE 802.1Q- 137 2003). In the solution, VLANs are used to indicate root/leaf 138 attribute of a packet: one VLAN ID is used to indicate the frames 139 originated from the roots and another VLAN ID is used to indicate the 140 frames originated from the leaves. At a leaf port, the bridge can 141 then filter out all the frames from other leaf ports based on the 142 VLAN ID. It is better to reuse the same mechanism in VPLS than to 143 develop a new mechanism. The latter will introduce more complexity to 144 interwork with IEEE 802.1Q solution. 146 This document introduces how the Ethernet VLAN solution can be used 147 to support generic E-Tree services in the VPLS. The solution proposed 148 here is fully compatible with the IEEE bridge architecture and the 149 IETF PWE3 technology, thus it will not change the FIB (such as 150 installing E-Tree attributes in the FIB), or need any specially 151 tailored implementation. Furthermore, VPLS scalability and simplicity 152 is also well kept. With this mechanism, it is also convenient to 153 deploy a converged E-Tree service across both Ethernet and MPLS 154 networks. 156 Firstly, a typical VPLS PE model is introduced as an example; the 157 model is then extended in which a Tree VSI is connected to a VLAN 158 bridge with a dual-VLAN interface. 160 This document then discusses the PW encapsulation and PW processing 161 such as VLAN mapping options for transporting E-Tree services in a 162 VPLS. 164 Finally, it describes the signaling extensions for E-Tree support and 165 PE processing procedures. 167 2. Conventions used in this document 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 3. Terminology 175 E-Tree: a Rooted-Multipoint EVC service as defined in MEF 6.1 177 EVC: Ethernet Virtual Connection, as defined in MEF 4.0 179 FIB: Forwarding Information Base, or forwarding table 180 T-VSI: Tree VSI, a VSI with E-Tree support 182 Root AC, an AC attached with a root 184 Leaf AC, an AC attached with a leaf 186 C-VLAN, Customer VLAN 188 S-VLAN, Service VLAN 190 B-VLAN, Backbone VLAN 192 Root VLAN, a VLAN ID used to indicate all the frames that are 193 originated at a root AC 195 Leaf VLAN, a VLAN ID used to indicate all the frames that are 196 originated at a leaf AC 198 I-SID, Backbone Service Instance Identifier, as defined in IEEE 199 802.1ah 201 4. PE Model with E-Tree Support 203 "VPLS only" PE architecture as shown in Fig. 1 of [Etree-req] is a 204 simplification of the VPLS and PWE3 architecture, several common VPLS 205 PE architectures are discussed in more details in [RFC4664] and 206 [RFC6246]. 208 Therefore, VLAN based E-Tree solution are demonstrated with the help 209 of a typical VPLS PE model. It can also be used by other PE models 210 which are discussed in Appendix A. 212 4.1. Existing PE Models 214 According to [RFC4664], there are at least three models possible for 215 a VPLS PE, including: 217 o A single bridge module, a single VSI; 219 o A single bridge module, multiple VSIs; 221 o Multiple bridge modules, each attaches to a VSI. 223 The second PE model is commonly used. A typical example is further 224 depicted in Fig. 1 and Fig. 2 [RFC6246], where an S-VLAN bridge 225 module is connected to multiple VSIs each with a single VLAN virtual 226 interface. 228 +-------------------------------+ 229 | 802.1ad Bridge Module Model | 230 | | 231 +---+ | +------+ +-----------+ | 232 |CE |---------|C-VLAN|------| | | 233 +---+ | |bridge|------| | | 234 | +------+ | | | 235 | o | S-VLAN | | 236 | o | | | 237 | o | Bridge | | 238 +---+ | +------+ | | | 239 |CE |---------|C-VLAN|------| | | 240 +---+ | |bridge|------| | | 241 | +------+ +-----------+ | 242 +-------------------------------+ 244 Figure 1 A model of 802.1ad Bridge Module 246 +----------------------------------------+ 247 | VPLS-capable PE model | 248 | +---------------+ +------+ | 249 | | | |VSI-1 |------------ 250 | | |==========| |------------ PWs 251 | | Bridge ------------ |------------ 252 | | | S-VLAN-1 +------+ | 253 | | Module | o | 254 | | | o | 255 | | (802.1ad | o | 256 | | bridge) | o | 257 | | | o | 258 | | | S-VLAN-n +------+ | 259 | | ------------VSI-n |------------- 260 | | |==========| |------------- PWs 261 | | | ^ | |------------- 262 | +---------------+ | +------+ | 263 | | | 264 +-------------------------|--------------+ 265 LAN emulation Interface 267 Figure 2 A VPLS-capable PE Model 269 In this PE model, Ethernet frames from Customer Edges (CEs) will 270 cross multiple stages of bridge modules (i.e., C-VLAN and S-VLAN 271 bridge) and a VSI in a PE before being sent on the PW to a remote PE. 272 Therefore, the association between an AC port and a PW on a VSI as 273 required in [Vpls-etree] or [Etree-2PW] is difficult, sometimes even 274 impossible. 276 This model could be further enhanced: When Ethernet frames arrive at 277 a PE, a root VLAN or a leaf VLAN tag is added. Then the frames with 278 the root VLAN tag are transmitted both to the roots and the leaves, 279 while the frames with the leaf VLAN tag are transmitted to the roots 280 but dropped for the leaves (these VLAN tags are removed before the 281 frames are transmitted over the wire). It was demonstrated in 282 [802.1aq] that the E-Tree service in Ethernet networks can be well 283 supported with this mechanism. 285 Assuming this mechanism is implemented in the bridge module, it is 286 quite straightforward to infer a VPLS PE model with two VSIs to 287 support the E-Tree (as shown in Fig. 3). But this model will require 288 two VSIs per PE and two sets of PWs per E-Tree service, which is 289 poorly scalable in a large MPLS/VPLS network; in addition, both these 290 VSIs have to share their learned MAC addresses. 292 +----------------------------------------+ 293 | VPLS-capable PE model | 294 | +---------------+ +------+ | 295 | | | |VSI-1 |------------ 296 | | |==========| |------------ PWs 297 | | Bridge ------------ |------------ 298 | | | Root +------+ | 299 | | Module | S-VLAN | 300 | | | | 301 | | (802.1ad | | 302 | | bridge) | | 303 | | | Leaf | 304 | | | S-VLAN +------+ | 305 | | ------------VSI-2 |------------- 306 | | |==========| |------------- PWs 307 | | | ^ | |------------- 308 | +---------------+ | +------+ | 309 | | | 310 +-------------------------|--------------+ 311 LAN emulation Interface 313 Figure 3 A VPLS PE Model for E-Tree with 2 VSIs 315 4.2. A New PE Model with E-Tree Support 317 In order to support the E-Tree in a more scalable way, a new VPLS PE 318 model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is 319 proposed. As depicted in Fig. 4, the bridge module is connected to 320 the T-VSI with a dual-VLAN virtual interface, i.e., both the root 321 VLAN and the leaf VLAN are connected to the same T-VSI, and they 322 share the same FIB and work in shared VLAN learning. In this way, 323 only one VPLS instance and one set of PWs is needed per E-Tree 324 service, and the scalability of VPLS is improved. 326 +----------------------------------------+ 327 | VPLS-capable PE model | 328 | +---------------+ +------+ | 329 | | |==========|TVSI-1|------------ 330 +---+AC | | ------------ |------------ PWs 331 |CE |-------| Bridge ------------ |------------ 332 +---+ | | | Root & +------+ | 333 | | Module | Leaf VLAN o | 334 | | | o | 335 | | | o | 336 | | | o | 337 | | | o | 338 +---+AC | | | VLAN-n +------+ | 339 |CE |-------| ------------VSI-n |------------- 340 +---+ | | |==========| |------------- PWs 341 | | | ^ | |------------- 342 | +---------------+ | +------+ | 343 | | | 344 +-------------------------|--------------+ 345 LAN emulation Interface 347 Figure 4 A VPLS PE Model for E-Tree with a Single T-VSI 349 For an untagged port (customer sites attached to the PEs with 350 untagged ports), the Ethernet frames received from the root ACs can 351 be tagged with a root C-VLAN, and optionally be added with another 352 root S-VLAN. Alternatively, the frames from the root ACs can be 353 tagged with the root S-VLAN tag directly in the VPLS network domain. 355 For a C-VLAN tagged port, the Ethernet frames received from the root 356 ACs can be added with a root S-VLAN. Alternatively, the C-VLAN can be 357 translated to the root S-VLAN in the VPLS network domain. 359 For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames 360 received from the root ACs can be translated to the root S-VLAN in 361 the VPLS network domain. Alternatively, the PBB VPLS PE model (where 362 an IEEE 802.1ah bridge module is embedded in the PE) as described in 363 [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added 364 in this case (the E-Tree attribute may also be indicated with two I- 365 SID tags in the bridge module, and the frames are further 366 encapsulated and transported transparently over a single B-VLAN, thus 367 the PBB VPLS works just in the same way as described in [PBB-VPLS] 368 and will be discussed no more in this document). When many S-VLANs 369 are multiplexed in a single AC, the 2nd option has an advantage of 370 both VLAN scalability and MAC address scalability. 372 In a similar way, the traffic from the leaf ACs is tagged and 373 transported on the leaf C-VLAN, S-VLAN or B-VLAN. 375 In all cases, the outermost VLAN in the resulted Ethernet header is 376 used to indicate the E-Tree attribute of an Ethernet frame; this 377 document will use VLAN to refer to this outermost VLAN for simplicity 378 in the latter sections. 380 5. PW for E-Tree Support 382 5.1. PW Encapsulation 384 To support an E-Tree service, T-VSIs in a VPLS must be interconnected 385 with a bidirectional Ethernet PW. The Ethernet PW may work in the 386 tagged mode (PW type 0x0004) as described in [RFC4448], and a VLAN 387 tag must be carried in each frame in the PW to indicate the frame 388 originated from either root or leaf (the VLAN tag indicating the 389 frame originated from either root or leaf can be translated by a 390 bridge module in the PE or added by an outside Ethernet edge device, 391 even by a customer device). In the tagged PW mode, two service 392 delimiting VLANs must be allocated in the VPLS domain for an E-Tree. 393 PW processing for the tagged PW will be described in Section 5.3 of 394 this document. 396 Raw PW (PW type 0x0005 in [RFC4448]) may be used to carry E-Tree 397 service for a PW in Compatible mode as shown in Section 5.3.2. 399 5.2. VLAN Mapping 401 There are two ways of manipulating VLANs for an E-Tree in VPLS: 403 o Global VLAN based, that is, provisioning two global VLANs (Root 404 VLAN, Leaf VLAN) across the VPLS network, thus no VLAN mapping is 405 needed at all, or the VLAN mapping is done completely in the 406 Ethernet domains. 408 o Local VLAN based, that is, provisioning two local VLANs for each 409 PE (which participates in the E-Tree) in the VPLS network 410 independently. 412 The first method requires no VLAN mapping in the PW, but two unique 413 service delimiting VLANs must be allocated across the VPLS domain. 415 The second method is more scalable in the use of VLANs, but needs a 416 VLAN mapping mechanism in the PW similar to what is already described 417 in Section 4.3 of [RFC4448]. 419 Global or local VLANs can be manually configured or provisioned by an 420 OSS system. Alternatively, some automatic VLAN allocation algorithm 421 may be provided in the management plane, but it is out scope of this 422 document. 424 For both methods, VLAN mapping parameters from a remote PE can be 425 provisioned or determined by a signaling protocol as described in 426 Section 6 when a PW is being established. 428 5.3. PW Processing 430 5.3.1.PW Processing in the VLAN Mapping Mode 432 In the VLAN Mapping mode, two VPLS PEs with E-Tree capability are 433 inter-connected with a PW (For example, the scenario of Fig. 5 434 depicts the interconnection of two PEs miscellaneously attached with 435 both root and leaf nodes). 437 +------------------------+ 438 | VPLS PE with T-VSI | 439 | | 440 +----+ | +------+ +-----+ | PW 441 |Root|------| VLAN |-------|T-VSI|---------- 442 +----+ | | BRG | | |---------- 443 +----+ | | |-------| |---------- 444 |Leaf|------| | | |---------+ 445 +----+ | +------+ +-----+ | | 446 | | | 447 +------------------------+ | 448 | 449 +------------------------+ | 450 | VPLS PE with T-VSI | | 451 | | | 452 +----+ | +------+ +-----+ | PW | 453 |Root|------| VLAN |-------|T-VSI|---------+ 454 +----+ | | BRG | | |---------- 455 +----+ | | |-------| |---------- 456 |Leaf|------| | | |---------- 457 +----+ | +------+ +-----+ | 458 | | 459 +------------------------+ 461 Figure 5 T-VSI Interconnected in the Normal Mode 463 If a PE is in the VLAN mapping mode for a PW, then in the data plane 464 the PE MUST map the VLAN in each frame as follows: 466 o Upon transmitting frames on the PW, map from local VLAN to remote 467 VLAN (i.e., the local leaf VLAN in a frame is translated to the 468 remote leaf VLAN; the local root VLAN in a frame is translated to the 469 remote root VLAN). 471 o Upon receiving frames on the PW, map from remote VLAN to local VLAN, 472 and the frames are further forwarded or dropped in the egress bridge 473 module using the filtering mechanism as described in [802.1aq]. 475 5.3.2.PW Processing in the Compatible Mode 477 The new VPLS PE model can work in a traditional VPLS network 478 seamlessly in the compatibility mode. As shown in Fig. 6, the VPLS PE 479 with T-VSI can be attached with root and/or leaf nodes, while the 480 VPLS PE with a traditional VSI can only be attached with root nodes. 481 Raw PW should be used to connect with a traditional PE. 483 +------------------------+ 484 | VPLS PE with T-VSI | 485 | | 486 +----+ | +------+ +-----+ | PW 487 |Root|------| VLAN |-------|T-VSI|---------- 488 +----+ | | BRG | | |---------- 489 +----+ | | |-------| |---------- 490 |Leaf|------| | | |---------+ 491 +----+ | +------+ +-----+ | | 492 | | | 493 +------------------------+ | 494 | 495 +------------------------+ | 496 | VPLS PE with VSI | | 497 | | | 498 +----+ | +------+ +-----+ | PW | 499 |Root|------| VLAN |-------|VSI |---------+ 500 +----+ | | BRG | | |---------- 501 +----+ | | | | |---------- 502 |Root|------| | | |---------- 503 +----+ | +------+ +-----+ | 504 | | 505 +------------------------+ 507 Figure 6 T-VSI interconnected with Traditional VSI 509 If a PE is in the Compatible mode for a PW, then in the data plane 510 the PE MUST process the frame as follows: 512 o Upon transmitting frames on the PW, remove the root or leaf VLAN in 513 the frames. 515 o Upon receiving frames on the PW, add a VLAN tag with a value of the 516 local root VLAN to the frames. 518 5.3.3.PW Processing in the Optimized Mode 520 When two PEs are connected with their T-VSIs and one PE (e.g., PE2) 521 is attached with only leaf nodes, as shown in the scenario of Fig. 6, 522 the peer PE (e.g., PE1) should then work in the optimization mode. In 523 this case, PE1 should not send the frames originated from the local 524 leaf VLAN to PE2, i.e., these frames are dropped rather than 525 transported over the PW. The bandwidth efficiency of the VPLS can 526 thus be improved. The signaling for the PE attached with only leaf 527 nodes is specified in Section 6. 528 +------------------------+ 529 |VPLS PE with T-VSI (PE1)| 530 | | 531 +----+ | +------+ +-----+ | PW 532 |Root|------| VLAN |-------|T-VSI|---------- 533 +----+ | | BRG | | |---------- 534 +----+ | | |-------| |---------- 535 |Leaf|------| | | |---------+ 536 +----+ | +------+ +-----+ | | 537 | | | 538 +------------------------+ | 539 | 540 +------------------------+ | 541 |VPLS PE with T-VSI (PE2)| | 542 | | | 543 +----+ | +------+ +-----+ | PW | 544 |Leaf|------| VLAN |-------|T-VSI|---------+ 545 +----+ | | BRG | | |---------- 546 +----+ | | |-------| |---------- 547 |Leaf|------| | | |---------- 548 +----+ | +------+ +-----+ | 549 | | 550 +------------------------+ 552 Figure 7 T-VSI interconnected with PE attached with only leaf nodes 554 If a PE is in the Optimized Mode for a PW, upon transmit, the PE 555 SHOULD first operate as follows: 557 o Drop a frame if its VLAN ID matches the local leaf VLAN ID. 559 6. LDP Extensions for E-Tree Support 561 In addition to the signaling procedures as specified in [RFC4447], 562 this document proposes a new interface parameter sub-TLV to provision 563 an E-Tree service and negotiate the VLAN mapping function, as follows: 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | E-Tree | Length=8 | Reserved |P|V| 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Root VLAN ID | Leaf VLAN ID | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Figure 8 E-Tree Sub-TLV 574 Where: 576 o E-Tree is the sub-TLV identifier to be assigned by IANA. 578 o Length is the length of the sub TLV in octets. 580 o Reserved bits MUST be set to zero on transmit and be ignored on 581 receive. 583 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 584 attached with only leaf nodes, and set to 0 otherwise. 586 o V is a bit indicating the sender's VLAN mapping capability. A PE 587 capable of VLAN mapping MUST set this bit, and clear it otherwise. 589 o Root VLAN ID is the value of the local root VLAN. 591 o Leaf VLAN ID is the value of the local leaf VLAN. 593 When setting up a PW for the E-Tree based VPLS, two PEs negotiate the 594 E-Tree support using the above E-Tree sub-TLV. Note PW type of 0x0004 595 should be used during the PW negotiation. 597 A PE that wishes to support E-Tree service MUST include an E-Tree 598 Sub-TLV in its PW label mapping message and include its local root 599 VLAN ID and leaf VLAN ID in the TLV. A PE that has the VLAN mapping 600 capability MUST set the V bit to 1, and a PE is attached with only 601 leaf nodes SHOULD set the P bit to 1. 603 In default, for each PW, VLAN-Mapping-Mode, Compatible-Mode, and 604 Optimized-Mode are all set to FALSE. 606 A PE that receives a PW label mapping message with an E-Tree Sub-TLV 607 from its peer PE must process it as follows: 609 1) if the root and leaf VLAN ID in the message match the local root 610 and leaf VLAN ID, then continue to 3); 612 2) else { 614 if the bit V is cleared, then { 616 if the PE is capable of VLAN mapping, then it MUST set 617 VLAN-Mapping-Mode to TRUE; 619 else { 621 A label release message with the error code "E-Tree 622 VLAN mapping not supported" is sent to the peer PE 623 and exit the process; 625 } 627 } 629 if the bit V is set, and the PE is capable of VLAN mapping, 630 then the PE with the minimum IP address MUST set VLAN-Mapping- 631 Mode to TRUE; 633 } 635 3) If the P bit is set, then: 637 { 639 If the PE is a leaf-only node itself, then a label release 640 message with a status code "Leaf to Leaf PW released" is sent to 641 the peer PE and exit the process; 643 Else the PE SHOULD set the Optimized-Mode to TRUE. 645 } 647 If a PE has sent an E-Tree Sub-TLV but does not receive any E-Tree 648 Sub-TLV in its peer's PW label mapping message, The PE SHOULD then 649 establish a raw PW with this peer as in traditional VPLS and set 650 Compatible-Mode to TRUE for this PW. 652 Data plane processing for this PW is as following: 654 If Optimized-Mode is TRUE, then data plane processing as described in 655 Section 5.3.3 applies. 657 If VLAN-Mapping-Mode is TRUE, then data plane processing as 658 described in Section 5.3.1 applies. 660 If Compatible-Mode is TRUE, then data plane processing is as 661 described in Section 5.3.2. 663 PW processing as described in [RFC4448] proceeds as usual for all 664 cases. 666 7. BGP Extensions for E-Tree Support 668 A new E-Tree extended community is proposed for E-Tree signaling in 669 BGP VPLS: 671 +------------------------------------+ 672 | Extended community type (2 octets) | 673 +------------------------------------+ 674 | Root VLAN (2 octets) | 675 +------------------------------------+ 676 | Leaf VLAN (2 octets) | 677 +------------------------------------+ 678 | Reserved |P| 679 +------------------------------------+ 681 Figure 9 E-Tree Extended Community 683 Where: 685 o Root VLAN ID is the value of the local root VLAN. 687 o Leaf VLAN ID is the value of the local leaf VLAN. 689 o Reserved, 15 bits MUST be set to zero on transmit and be ignored 690 on receive. 692 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 693 attached with only leaf nodes, and set to 0 otherwise. 695 The PEs attached with both leaf and root nodes must support BGP E- 696 Tree signaling as described in this document, and must support VLAN 697 mapping in their data planes. The traditional PE attached with only 698 root nodes may also participate in an E-Tree service. 700 In BGP VPLS signaling, besides attaching a Layer2 Info Extended 701 Community as detailed in [RFC4761], an E-Tree Extended Community MUST 702 be further attached if a PE wishes to participate in an E-Tree 703 service. The PE MUST include its local root VLAN ID and leaf VLAN ID 704 in the E-Tree Extended Community. A PE attached with only leaf nodes 705 of an E-Tree SHOULD set the P bit in the E-Tree Extended Community to 706 1. 708 A PE that receives a BGP UPDATE message with an E-Tree Extended 709 Community from its peer PE must process it as follows (after 710 processing procedures as specified in Section 3.2 of [RFC4761]): 712 1) if the root and leaf VLAN ID in the E-Tree Extended Community 713 match the local root and leaf VLAN ID, then continue to 3); 715 2) else { 717 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 718 to TRUE; 720 } 722 3) If the P bit is set, then the PE SHOULD set the Optimized-Mode to 723 TRUE. 725 A PE which does not recognize this attribute shall ignore it silently. 726 If a PE has sent an E-Tree Extended Community but does not receive 727 any E-Tree Extended Community from its peer, the PE SHOULD then 728 establish a raw PW with this peer as in traditional VPLS, and set 729 Compatible-Mode to TRUE for this PW. 731 Data plane in the VPLS is the same as described in Section 4.2 of 732 [RFC4761], and data plane processing for a PW is the same as 733 described at the end of Section 6. 735 8. OAM Considerations 737 VPLS OAM requirements and framework as specified in [RFC6136] are 738 applicable to E-Tree, as both Ethernet OAM frames and data traffic 739 are transported over the same PW. 741 Ethernet OAM for E-Tree including both service OAM and segment OAM 742 frames shall undergo the same VLAN mapping as the data traffic; and 743 root VLAN SHOULD be applied to segment OAM frames so that they are 744 not filtered. 746 9. Applicability 748 The solution is applicable to both LDP VPLS [RFC4762] and BGP VPLS 749 [RFC4761]. 751 The solution is applicable to both "VPLS Only" networks and VPLS with 752 Ethernet aggregation networks. 754 The solution is also applicable to PBB VPLS networks. 756 10. Security Considerations 758 Besides security considerations as described in [RFC4448], [RFC4761] 759 and [RFC4762], this solution prevents leaf to leaf communication in 760 the data plane of VPLS when its PEs are interconnected with PWs. In 761 this regard, security can be enhanced for customers with this 762 solution. 764 11. IANA Considerations 766 IANA is requested to allocate a value for E-Tree in the registry of 767 Pseudowire Interface Parameters Sub-TLV type. 769 Parameter ID Length Description 770 ======================================= 771 TBD 8 E-Tree 773 IANA is requested to allocate two new LDP status codes from the 774 registry of name "STATUS CODE NAME SPACE". The following values are 775 suggested: 777 Range/Value E Description 778 ------------- ----- ---------------------- 779 TBD 1 E-Tree VLAN mapping not supported 780 TBD 0 Leaf to Leaf PW released 782 IANA is requested to allocate a value for E-Tree in the registry of 783 BGP Extended Community. 785 Type Value Name 786 ======================================= 787 TBD E-Tree Info 789 12. References 791 12.1. Normative References 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, March 1997. 796 [RFC4447] Martini, L., and et al, "Pseudowire Setup and Maintenance 797 Using Label Distribution Protocol (LDP)", RFC 4447, April 798 2006. 800 [RFC4448] Martini, L., and et al, "Encapsulation Methods for 801 Transport of Ethernet over MPLS Networks", RFC 4448, April 802 2006. 804 [RFC4761] Kompella, K. and Rekhter, Y., "Virtual Private LAN Service 805 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 806 4761, January 2007 808 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN 809 Services using LDP", RFC 4762, January 2007. 811 [RFC6136] Sajassi, A. and Mohan, D., "L2VPN OAM Requirements and 812 Framework", RFC 6136, March 2011 814 12.2. Informative References 816 [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to- 817 Edge (PWE3) Architecture", RFC 3985, March 2005. 819 [RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2 820 Virtual Private Networks (L2VPNs)", RFC 4664, September 821 2006. 823 [RFC6246] Sajassi, A., and et al, "Virtual Private LAN Service (VPLS) 824 Interoperability with Customer Edge (CE) Bridges", RFC 6246, 825 June 2011 827 [ETree-req] Key, R., et al, "Requirements for MEF E-Tree Support in 828 VPLS", draft-ietf-l2vpn-etree-reqt-01, Work in Progress 830 [Vpls-etree] Key, R., and et al, "Extension to VPLS for E-Tree", 831 draft-key-l2vpn-vpls-etree-06, October 2011 833 [802.1aq] IEEE 802.1aq D4.3, Virtual Bridged Local Area Networks - 834 Amendment 9: Shortest Path Bridging, September 2011 836 [Etree-2PW] Ram, R., and et al., Extension to LDP-VPLS for E-Tree 837 Using Two PW, draft-ram-l2vpn-ldp-vpls-etree-2pw-02, May 838 2011 840 [PBB-VPLS] Balus, F., and et al., Extensions to VPLS PE model for 841 Provider Backbone Bridging, draft-ietf-l2vpn-pbb-vpls-pe- 842 model-04, October 2011 844 13. Acknowledgments 846 The authors would like to thank Adrian Farrel, Susan Hares and Shane 847 Amante for their valuable advices, thank Ben Mack-crane, Edwin 848 Mallette, Donald Fedyk, Dave Allan, Giles Heron, Raymond Key, Josh 849 Rogers, Sam Cao and Daniel Cohn for their valuable comments and 850 discussions. 852 Appendix A. Other PE Models for E-Tree 854 A.1. A PE Model With a VSI and No bridge 856 If there is no bridge module in a PE, the PE may consist of Native 857 Service Processors (NSPs) as shown in Figure A.1 (adapted from Fig. 5 858 of [RFC3985]) where any transformation operation for VLANs (e.g., 859 VLAN insertion/removal or VLAN mapping) may be applied. Thus a root 860 VLAN or leaf VLAN can be added by the NSP depending on the UNI type 861 (root/leaf) associated with the AC over which the packet arrives. 863 Further, when a packet with a leaf VLAN exits a forwarder and arrives 864 at the NSP, the NSP must drop the packet if the egress AC is 865 associated with a leaf UNI. 867 Tagged PW and VLAN mapping work in the same way as in the typical PE 868 model. 870 +----------------------------------------+ 871 | PE Device | 872 Multiple+----------------------------------------+ 873 AC | | | Single | PW Instance 874 <------>o NSP # + PW Instance X<----------> 875 | | | | 876 |------| VSI |----------------------| 877 | | | Single | PW Instance 878 <------>o NSP #Forwarder + PW Instance X<----------> 879 | | | | 880 |------| |----------------------| 881 | | | Single | PW Instance 882 <------>o NSP # + PW Instance X<----------> 883 | | | | 884 +----------------------------------------+ 886 Figure A.1 A PE model with a VSI and no bridge module 888 This PE model may be used by an MTU-s in an H-VPLS network, or an N- 889 PE in an H-VPLS network with non-bridging edge devices, wherein a 890 spoke PW can be treated as an AC in this model. 892 A.2. A PE Model With external E-Tree interface 894 +----------------------------------------+ 895 | PE Device | 896 Root +----------------------------------------+ 897 VLAN | | Single | PW Instance 898 <------>o + PW Instance X<----------> 899 | | | 900 | VSI |----------------------| 901 | | Single | PW Instance 902 | Forwarder + PW Instance X<----------> 903 | | | 904 Leaf | |----------------------| 905 VLAN | | Single | PW Instance 906 <------>o + PW Instance X<----------> 907 | | | 908 +----------------------------------------+ 910 Figure A.2 A PE model with external E-Tree interface 912 A more simplified PE model is depicted in A.2, where Root/Leaf VLANs 913 are directly or indirectly over a single PW connected to a same VSI 914 forwarder in a PE, any transformation of E-Tree VLANs, e.g., VLAN 915 insertion/removal or VLAN mapping, can be performed by some outer 916 equipments, and the PE may further translate these VLANs into its own 917 local VLANs. This PE model may be used by an N-PE in an H-VPLS 918 network with bridging-capable devices, or scenarios such as providing 919 E-Tree Network-to-Network (NNI) interfaces. 921 Authors' Addresses 923 Yuanlong Jiang 924 Huawei Technologies Co., Ltd. 925 Bantian, Longgang district 926 Shenzhen 518129, China 927 Email: jiangyuanlong@huawei.com 929 Lucy Yong 930 Huawei USA 931 1700 Alma Dr. Suite 500 932 Plano, TX 75075, USA 933 Email: lucyyong@huawei.com 935 Manuel Paul 936 Deutsche Telekom 937 Winterfeldtstr. 21 938 10781 Berlin, Germany 939 Email: manuel.paul@telekom.de 941 Frederic Jounay 942 Orange CH 943 4 rue caudray 1020 Renens, Switzerland 944 Email: frederic.jounay@orange.ch 946 Florin Balus 947 Alcatel-Lucent 948 701 E. Middlefield Road 949 Mountain View, CA, USA 94043 950 Email: florin.balus@alcatel-lucent.com 952 Wim Henderickx 953 Alcatel-Lucent 954 Copernicuslaan 50 955 2018 Antwerp, Belgium 956 Email: wim.henderickx@alcatel-lucent.com 958 Ali Sajassi 959 Cisco 960 170 West Tasman Drive 961 San Jose, CA 95134, USA 962 Email: sajassi@cisco.com