idnits 2.17.1 draft-ietf-l2vpn-vpls-pe-etree-01.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 869 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 (February 5, 2013) is 4091 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 204, but not defined == Unused Reference: 'ETree-req' is defined on line 838, 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 (~~), 8 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: August 2013 February 5, 2013 20 VPLS PE Model for E-Tree Support 21 draft-ietf-l2vpn-vpls-pe-etree-01.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 August 5, 2013. 45 Copyright Notice 47 Copyright (c) 2013 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. 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 ...................................... 18 93 11. References ............................................... 19 94 11.1. Normative References ............................... 19 95 11.2. Informative References ............................. 19 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. Introduction 103 The E-Tree service is defined in Metro Ethernet Forum (MEF) as a 104 Rooted-Multipoint EVC service. It is a multipoint Ethernet service 105 with special restrictions: the frames from a root may be received by 106 any other root or leaf, and the frames from a leaf may be received by 107 any root, but MUST not be received by a leaf. Further, an E-Tree 108 service may include multiple roots and multiple leaves. Although VPMS 109 or P2MP multicast is a somewhat simplified version of this service, 110 in fact, there is no exact corresponding terminology in IETF. 112 [Etree-req] gives the requirements for providing E-Tree solutions in 113 the VPLS and the need to filter leaf-to-leaf traffic. 115 [Vpls-etree] describes a PW control word based E-Tree solution, where 116 a bit in the PW control word is used to indicate the root/leaf 117 attribute for a packet. The Ethernet forwarder in the VPLS is also 118 extended to filter the leaf-to-leaf traffic based on the tuple. 121 [Etree-2PW] proposes another E-Tree solution where root and leaf 122 traffic are classified and forwarded in the same VSI but with two 123 separate PWs. 125 Both solutions are only applicable to "VPLS only" networks. 127 In fact, VPLS PE usually consists of a bridge module itself (see 128 [RFC4664] and [RFC6246]); moreover, E-Tree services may cross both 129 Ethernet and VPLS domains. Therefore, it is necessary to develop an 130 E-Tree solution both for "VPLS only" scenarios and for interworking 131 between Ethernet and VPLS. 133 IEEE 802.1 has incorporated the generic E-Tree solution in the latest 134 version of 802.1Q [802.1aq], which is just an improvement on the 135 traditional asymmetric VLAN mechanism (the use of different VLANs to 136 indicate E-Tree root/leaf attributes and prohibiting leaf-to-leaf 137 traffic with the help of VLANs was first standardized in IEEE 802.1Q- 138 2003). In the solution, VLANs are used to indicate root/leaf 139 attribute of a packet: one VLAN ID is used to indicate the frames 140 originated from the roots and another VLAN ID is used to indicate the 141 frames originated from the leaves. At a leaf port, the bridge can 142 then filter out all the frames from other leaf ports based on the 143 VLAN ID. It is better to reuse the same mechanism in VPLS than to 144 develop a new mechanism. The latter will introduce more complexity to 145 interwork with IEEE 802.1Q solution. 147 This document introduces how the Ethernet VLAN solution can be used 148 to support generic E-Tree services in the VPLS. The solution proposed 149 here is fully compatible with the IEEE bridge architecture and the 150 IETF PWE3 technology, thus it will not change the FIB (such as 151 installing E-Tree attributes in the FIB), or need any specially 152 tailored implementation. Furthermore, VPLS scalability and simplicity 153 is also well kept. With this mechanism, it is also convenient to 154 deploy a converged E-Tree service across both Ethernet and MPLS 155 networks. 157 Firstly, a typical VPLS PE model is introduced as an example; the 158 model is then extended in which a Tree VSI is connected to a VLAN 159 bridge with a dual-VLAN interface. 161 This document then discusses the PW encapsulation and PW processing 162 such as VLAN mapping options for transporting E-Tree services in a 163 VPLS. 165 Finally, it describes the signaling extensions for E-Tree support and 166 PE processing procedures. 168 2. Conventions used in this document 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 3. Terminology 176 E-Tree: a Rooted-Multipoint EVC service as defined in MEF 6.1 178 EVC: Ethernet Virtual Connection, as defined in MEF 4.0 179 FIB: Forwarding Information Base, or forwarding table 181 T-VSI: Tree VSI, a VSI with E-Tree support 183 Root AC, an AC attached with a root 185 Leaf AC, an AC attached with a leaf 187 C-VLAN, Customer VLAN 189 S-VLAN, Service VLAN 191 B-VLAN, Backbone VLAN 193 Root VLAN, a VLAN ID used to indicate all the frames that are 194 originated at a root AC 196 Leaf VLAN, a VLAN ID used to indicate all the frames that are 197 originated at a leaf AC 199 I-SID, Backbone Service Instance Identifier, as defined in IEEE 200 802.1ah 202 4. PE Model with E-Tree Support 204 "VPLS only" PE architecture as shown in Fig. 1 of [Etree-req] is a 205 simplification of the VPLS and PWE3 architecture, several common VPLS 206 PE architectures are discussed in more details in [RFC4664] and 207 [RFC6246]. 209 Therefore, VLAN based E-Tree solution are demonstrated with the help 210 of a typical VPLS PE model. It can also be used by other PE models 211 which are discussed in Appendix A. 213 4.1. Existing PE Models 215 According to [RFC4664], there are at least three models possible for 216 a VPLS PE, including: 218 o A single bridge module, a single VSI; 220 o A single bridge module, multiple VSIs; 222 o Multiple bridge modules, each attaches to a VSI. 224 The second PE model is commonly used. A typical example is further 225 depicted in Fig. 1 and Fig. 2 [RFC6246], where an S-VLAN bridge 226 module is connected to multiple VSIs each with a single VLAN virtual 227 interface. 229 +-------------------------------+ 230 | 802.1ad Bridge Module Model | 231 | | 232 +---+ | +------+ +-----------+ | 233 |CE |---------|C-VLAN|------| | | 234 +---+ | |bridge|------| | | 235 | +------+ | | | 236 | o | S-VLAN | | 237 | o | | | 238 | o | Bridge | | 239 +---+ | +------+ | | | 240 |CE |---------|C-VLAN|------| | | 241 +---+ | |bridge|------| | | 242 | +------+ +-----------+ | 243 +-------------------------------+ 245 Figure 1 A model of 802.1ad Bridge Module 247 +----------------------------------------+ 248 | VPLS-capable PE model | 249 | +---------------+ +------+ | 250 | | | |VSI-1 |------------ 251 | | |==========| |------------ PWs 252 | | Bridge ------------ |------------ 253 | | | S-VLAN-1 +------+ | 254 | | Module | o | 255 | | | o | 256 | | (802.1ad | o | 257 | | bridge) | o | 258 | | | o | 259 | | | S-VLAN-n +------+ | 260 | | ------------VSI-n |------------- 261 | | |==========| |------------- PWs 262 | | | ^ | |------------- 263 | +---------------+ | +------+ | 264 | | | 265 +-------------------------|--------------+ 266 LAN emulation Interface 268 Figure 2 A VPLS-capable PE Model 270 In this PE model, Ethernet frames from Customer Edges (CEs) will 271 cross multiple stages of bridge modules (i.e., C-VLAN and S-VLAN 272 bridge) and a VSI in a PE before being sent on the PW to a remote PE. 273 Therefore, the association between an AC port and a PW on a VSI as 274 required in [Vpls-etree] or [Etree-2PW] is difficult, sometimes even 275 impossible. 277 This model could be further enhanced: When Ethernet frames arrive at 278 a PE, a root VLAN or a leaf VLAN tag is added. Then the frames with 279 the root VLAN tag are transmitted both to the roots and the leaves, 280 while the frames with the leaf VLAN tag are transmitted to the roots 281 but dropped for the leaves (these VLAN tags are removed before the 282 frames are transmitted over the wire). It was demonstrated in 283 [802.1aq] that the E-Tree service in Ethernet networks can be well 284 supported with this mechanism. 286 Assuming this mechanism is implemented in the bridge module, it is 287 quite straightforward to infer a VPLS PE model with two VSIs to 288 support the E-Tree (as shown in Fig. 3). But this model will require 289 two VSIs per PE and two sets of PWs per E-Tree service, which is 290 poorly scalable in a large MPLS/VPLS network; in addition, both these 291 VSIs have to share their learned MAC addresses. 293 +----------------------------------------+ 294 | VPLS-capable PE model | 295 | +---------------+ +------+ | 296 | | | |VSI-1 |------------ 297 | | |==========| |------------ PWs 298 | | Bridge ------------ |------------ 299 | | | Root +------+ | 300 | | Module | S-VLAN | 301 | | | | 302 | | (802.1ad | | 303 | | bridge) | | 304 | | | Leaf | 305 | | | S-VLAN +------+ | 306 | | ------------VSI-2 |------------- 307 | | |==========| |------------- PWs 308 | | | ^ | |------------- 309 | +---------------+ | +------+ | 310 | | | 311 +-------------------------|--------------+ 312 LAN emulation Interface 314 Figure 3 A VPLS PE Model for E-Tree with 2 VSIs 316 4.2. A New PE Model with E-Tree Support 318 In order to support the E-Tree in a more scalable way, a new VPLS PE 319 model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is 320 proposed. As depicted in Fig. 4, the bridge module is connected to 321 the T-VSI with a dual-VLAN virtual interface, i.e., both the root 322 VLAN and the leaf VLAN are connected to the same T-VSI, and they 323 share the same FIB and work in shared VLAN learning. In this way, 324 only one VPLS instance and one set of PWs is needed per E-Tree 325 service, and the scalability of VPLS is improved. 327 +----------------------------------------+ 328 | VPLS-capable PE model | 329 | +---------------+ +------+ | 330 | | |==========|TVSI-1|------------ 331 +---+AC | | ------------ |------------ PWs 332 |CE |-------| Bridge ------------ |------------ 333 +---+ | | | Root & +------+ | 334 | | Module | Leaf VLAN o | 335 | | | o | 336 | | | o | 337 | | | o | 338 | | | o | 339 +---+AC | | | VLAN-n +------+ | 340 |CE |-------| ------------VSI-n |------------- 341 +---+ | | |==========| |------------- PWs 342 | | | ^ | |------------- 343 | +---------------+ | +------+ | 344 | | | 345 +-------------------------|--------------+ 346 LAN emulation Interface 348 Figure 4 A VPLS PE Model for E-Tree with a Single T-VSI 350 For an untagged port (frames over this port are untagged) or VLAN- 351 unaware port (VLAN tags in the frames are ignored), the Ethernet 352 frames received from the root ACs SHOULD be tagged with a root C-VLAN, 353 and optionally MAY be added with another root S-VLAN. 355 For a C-VLAN tagged port, the Ethernet frames received from the root 356 ACs SHOULD be added with a root S-VLAN. 358 For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames 359 received from the root ACs SHOULD be translated to the root S-VLAN in 360 the VPLS network domain. Alternatively, the PBB VPLS PE model (where 361 an IEEE 802.1ah bridge module is embedded in the PE) as described in 362 [PBB-VPLS] MAY be used, and a root B-VLAN or leaf B-VLAN MAY be added 363 in this case (the E-Tree attribute may also be indicated with two I- 364 SID tags in the bridge module, and the frames are further 365 encapsulated and transported transparently over a single B-VLAN, thus 366 the PBB VPLS works just in the same way as described in [PBB-VPLS] 367 and will be discussed no more in this document). When many S-VLANs 368 are multiplexed in a single AC, the 2nd option has an advantage of 369 both VLAN scalability and MAC address scalability. 371 In a similar way, the traffic from the leaf ACs is tagged and 372 transported on the leaf C-VLAN, S-VLAN or B-VLAN. 374 In all cases, the outermost VLAN in the resulted Ethernet header is 375 used to indicate the E-Tree attribute of an Ethernet frame; this 376 document will use VLAN to refer to this outermost VLAN for simplicity 377 in the latter sections. 379 5. PW for E-Tree Support 381 5.1. PW Encapsulation 383 To support an E-Tree service, T-VSIs in a VPLS must be interconnected 384 with a bidirectional Ethernet PW. The Ethernet PW may work in the 385 tagged mode (PW type 0x0004) as described in [RFC4448], and a VLAN 386 tag must be carried in each frame in the PW to indicate the frame 387 originated from either root or leaf (the VLAN tag indicating the 388 frame originated from either root or leaf can be translated by a 389 bridge module in the PE or added by an outside Ethernet edge device, 390 even by a customer device). In the tagged PW mode, two service 391 delimiting VLANs must be allocated in the VPLS domain for an E-Tree. 392 PW processing for the tagged PW will be described in Section 5.3 of 393 this document. 395 Raw PW (PW type 0x0005 in [RFC4448]) may be used to carry E-Tree 396 service for a PW in Compatible mode as shown in Section 5.3.2. 398 5.2. VLAN Mapping 400 There are two ways of manipulating VLANs for an E-Tree in VPLS: 402 o Global VLAN based, that is, provisioning two global VLANs (Root 403 VLAN, Leaf VLAN) across the VPLS network, thus no VLAN mapping is 404 needed at all, or the VLAN mapping is done completely in the 405 Ethernet domains. 407 o Local VLAN based, that is, provisioning two local VLANs for each 408 PE (which participates in the E-Tree) in the VPLS network 409 independently. 411 The first method requires no VLAN mapping in the PW, but two unique 412 service delimiting VLANs must be allocated across the VPLS domain. 414 The second method is more scalable in the use of VLANs, but needs a 415 VLAN mapping mechanism in the PW similar to what is already described 416 in Section 4.3 of [RFC4448]. 418 Global or local VLANs can be manually configured or provisioned by an 419 OSS system. Alternatively, some automatic VLAN allocation algorithm 420 may be provided in the management plane, but it is out scope of this 421 document. 423 For both methods, VLAN mapping parameters from a remote PE can be 424 provisioned or determined by a signaling protocol as described in 425 Section 6 when a PW is being established. 427 5.3. PW Processing 429 5.3.1.PW Processing in the VLAN Mapping Mode 431 In the VLAN Mapping mode, two VPLS PEs with E-Tree capability are 432 inter-connected with a PW (For example, the scenario of Fig. 5 433 depicts the interconnection of two PEs miscellaneously attached with 434 both root and leaf nodes). 436 +------------------------+ 437 | VPLS PE with T-VSI | 438 | | 439 +----+ | +------+ +-----+ | PW 440 |Root|------| VLAN |-------|T-VSI|---------- 441 +----+ | | BRG | | |---------- 442 +----+ | | |-------| |---------- 443 |Leaf|------| | | |---------+ 444 +----+ | +------+ +-----+ | | 445 | | | 446 +------------------------+ | 447 | 448 +------------------------+ | 449 | VPLS PE with T-VSI | | 450 | | | 451 +----+ | +------+ +-----+ | PW | 452 |Root|------| VLAN |-------|T-VSI|---------+ 453 +----+ | | BRG | | |---------- 454 +----+ | | |-------| |---------- 455 |Leaf|------| | | |---------- 456 +----+ | +------+ +-----+ | 457 | | 458 +------------------------+ 460 Figure 5 T-VSI Interconnected in the Normal Mode 462 If a PE is in the VLAN mapping mode for a PW, then in the data plane 463 the PE MUST map the VLAN in each frame as follows: 465 o Upon transmitting frames on the PW, map from local VLAN to remote 466 VLAN (i.e., the local leaf VLAN in a frame is translated to the 467 remote leaf VLAN; the local root VLAN in a frame is translated to the 468 remote root VLAN). 470 o Upon receiving frames on the PW, map from remote VLAN to local VLAN, 471 and the frames are further forwarded or dropped in the egress bridge 472 module using the filtering mechanism as described in [802.1aq]. 474 The signaling for VLANs is specified in Section 6. 476 5.3.2.PW Processing in the Compatible Mode 478 The new VPLS PE model can work in a traditional VPLS network 479 seamlessly in the compatibility mode. As shown in Fig. 6, the VPLS PE 480 with T-VSI can be attached with root and/or leaf nodes, while the 481 VPLS PE with a traditional VSI can only be attached with root nodes. 482 A raw PW should be used to connect them. 484 +------------------------+ 485 | VPLS PE with T-VSI | 486 | | 487 +----+ | +------+ +-----+ | PW 488 |Root|------| VLAN |-------|T-VSI|---------- 489 +----+ | | BRG | | |---------- 490 +----+ | | |-------| |---------- 491 |Leaf|------| | | |---------+ 492 +----+ | +------+ +-----+ | | 493 | | | 494 +------------------------+ | 495 | 496 +------------------------+ | 497 | VPLS PE with VSI | | 498 | | | 499 +----+ | +------+ +-----+ | PW | 500 |Root|------| VLAN |-------|VSI |---------+ 501 +----+ | | BRG | | |---------- 502 +----+ | | | | |---------- 503 |Root|------| | | |---------- 504 +----+ | +------+ +-----+ | 505 | | 506 +------------------------+ 508 Figure 6 T-VSI interconnected with Traditional VSI 510 If a PE is in the Compatible mode for a PW, then in the data plane 511 the PE MUST process the frame as follows: 513 o Upon transmitting frames on the PW, remove the root or leaf VLAN in 514 the frames. 516 o Upon receiving frames on the PW, add a VLAN tag with a value of the 517 local root VLAN to the frames. 519 5.3.3.PW Processing in the Optimized Mode 521 When two PEs (both have E-Tree capability) are inter-connected and 522 one of them (e.g., PE2) is attached with only leaf nodes, as shown in 523 the scenario of Fig. 7, its peer PE (e.g., PE1) should then work in 524 the optimized mode. In this case, PE1 should not send the frames 525 originated from the local leaf VLAN to PE2, i.e., these frames are 526 dropped rather than transported over the PW. The bandwidth efficiency 527 of the VPLS can thus be improved. The signaling for the PE attached 528 with only leaf nodes is specified in Section 6. 529 +------------------------+ 530 |VPLS PE with T-VSI (PE1)| 531 | | 532 +----+ | +------+ +-----+ | PW 533 |Root|------| VLAN |-------|T-VSI|---------- 534 +----+ | | BRG | | |---------- 535 +----+ | | |-------| |---------- 536 |Leaf|------| | | |---------+ 537 +----+ | +------+ +-----+ | | 538 | | | 539 +------------------------+ | 540 | 541 +------------------------+ | 542 |VPLS PE with T-VSI (PE2)| | 543 | | | 544 +----+ | +------+ +-----+ | PW | 545 |Leaf|------| VLAN |-------|T-VSI|---------+ 546 +----+ | | BRG | | |---------- 547 +----+ | | |-------| |---------- 548 |Leaf|------| | | |---------- 549 +----+ | +------+ +-----+ | 550 | | 551 +------------------------+ 553 Figure 7 T-VSI interconnected with PE attached with only leaf nodes 555 If a PE is in the Optimized Mode for a PW, upon transmit, the PE 556 SHOULD first operate as follows: 558 o Drop a frame if its VLAN ID matches the local leaf VLAN ID. 560 6. Signaling for E-Tree Support 562 6.1. LDP Extensions for E-Tree Support 564 In addition to the signaling procedures as specified in [RFC4447], 565 this document proposes a new interface parameter sub-TLV to provision 566 an E-Tree service and negotiate the VLAN mapping function, as follows: 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | E-Tree | Length=8 | Reserved |P|V| 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Root VLAN ID | Leaf VLAN ID | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 8 E-Tree Sub-TLV 577 Where: 579 o E-Tree is the sub-TLV identifier to be assigned by IANA. 581 o Length is the length of the sub TLV in octets. 583 o Reserved bits MUST be set to zero on transmit and be ignored on 584 receive. 586 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 587 attached with only leaf nodes, and set to 0 otherwise. 589 o V is a bit indicating the sender's VLAN mapping capability. A PE 590 capable of VLAN mapping MUST set this bit, and clear it otherwise. 592 o Root VLAN ID is the value of the local root VLAN. 594 o Leaf VLAN ID is the value of the local leaf VLAN. 596 When setting up a PW for the E-Tree based VPLS, two PEs negotiate the 597 E-Tree support using the above E-Tree sub-TLV. Note PW type of 0x0004 598 should be used during the PW negotiation. 600 A PE that wishes to support E-Tree service MUST include an E-Tree 601 Sub-TLV in its PW label mapping message and include its local root 602 VLAN ID and leaf VLAN ID in the TLV. A PE that has the VLAN mapping 603 capability MUST set the V bit to 1, and a PE is attached with only 604 leaf nodes SHOULD set the P bit to 1. 606 In default, for each PW, VLAN-Mapping-Mode, Compatible-Mode, and 607 Optimized-Mode are all set to FALSE. 609 A PE that receives a PW label mapping message with an E-Tree Sub-TLV 610 from its peer PE, after saving the VLAN information for the PW, must 611 process it as follows: 613 1) if the root and leaf VLAN ID in the message match the local root 614 and leaf VLAN ID, then continue to 3); 616 2) else { 618 if the bit V is cleared, then { 620 if the PE is capable of VLAN mapping, then it MUST set 621 VLAN-Mapping-Mode to TRUE; 623 else { 625 A label release message with the error code "E-Tree 626 VLAN mapping not supported" is sent to the peer PE 627 and exit the process; 629 } 631 } 633 if the bit V is set, and the PE is capable of VLAN mapping, 634 then the PE with the minimum IP address MUST set VLAN-Mapping- 635 Mode to TRUE; 637 } 639 3) If the P bit is set, then: 641 { 643 If the PE is a leaf-only node itself, then a label release 644 message with a status code "Leaf to Leaf PW released" is sent to 645 the peer PE and exit the process; 647 Else the PE SHOULD set the Optimized-Mode to TRUE. 649 } 651 If a PE has sent an E-Tree Sub-TLV but does not receive any E-Tree 652 Sub-TLV in its peer's PW label mapping message, The PE SHOULD then 653 establish a raw PW with this peer as in traditional VPLS and set 654 Compatible-Mode to TRUE for this PW. 656 Data plane processing for this PW is as following: 658 If Optimized-Mode is TRUE, then data plane processing as described in 659 Section 5.3.3 applies. 661 If VLAN-Mapping-Mode is TRUE, then data plane processing as described 662 in Section 5.3.1 applies. 664 If Compatible-Mode is TRUE, then data plane processing is as 665 described in Section 5.3.2. 667 PW processing as described in [RFC4448] proceeds as usual for all 668 cases. 670 6.2. BGP Extensions for E-Tree Support 672 A new E-Tree extended community is proposed for E-Tree signaling in 673 BGP VPLS: 675 +------------------------------------+ 676 | Extended community type (2 octets) | 677 +------------------------------------+ 678 | Root VLAN (2 octets) | 679 +------------------------------------+ 680 | Leaf VLAN (2 octets) | 681 +------------------------------------+ 682 | Reserved |P| 683 +------------------------------------+ 685 Figure 9 E-Tree Extended Community 687 Where: 689 o Root VLAN ID is the value of the local root VLAN. 691 o Leaf VLAN ID is the value of the local leaf VLAN. 693 o Reserved, 15 bits MUST be set to zero on transmit and be ignored 694 on receive. 696 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 697 attached with only leaf nodes, and set to 0 otherwise. 699 The PEs attached with both leaf and root nodes must support BGP E- 700 Tree signaling as described in this document, and must support VLAN 701 mapping in their data planes. The traditional PE attached with only 702 root nodes may also participate in an E-Tree service. 704 In BGP VPLS signaling, besides attaching a Layer2 Info Extended 705 Community as detailed in [RFC4761], an E-Tree Extended Community MUST 706 be further attached if a PE wishes to participate in an E-Tree 707 service. The PE MUST include its local root VLAN ID and leaf VLAN ID 708 in the E-Tree Extended Community. A PE attached with only leaf nodes 709 of an E-Tree SHOULD set the P bit in the E-Tree Extended Community to 710 1. 712 A PE that receives a BGP UPDATE message with an E-Tree Extended 713 Community from its peer PE, after saving the VLAN information for the 714 PW, must process it as follows (after processing procedures as 715 specified in Section 3.2 of [RFC4761]): 717 1) if the root and leaf VLAN ID in the E-Tree Extended Community 718 match the local root and leaf VLAN ID, then continue to 3); 720 2) else { 722 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 723 to TRUE; 725 } 727 3) If the P bit is set { 729 If the PE is a leaf-only PE itself, then forbids any traffic on 730 the PW; 732 Else the PE SHOULD set the Optimized-Mode to TRUE. 734 } 736 A PE which does not recognize this attribute shall ignore it silently. 737 If a PE has sent an E-Tree Extended Community but does not receive 738 any E-Tree Extended Community from its peer, the PE SHOULD then 739 establish a raw PW with this peer as in traditional VPLS, and set 740 Compatible-Mode to TRUE for this PW. 742 Data plane in the VPLS is the same as described in Section 4.2 of 743 [RFC4761], and data plane processing for a PW is the same as 744 described at the end of Section 6.1. 746 7. OAM Considerations 748 VPLS OAM requirements and framework as specified in [RFC6136] are 749 applicable to E-Tree, as both Ethernet OAM frames and data traffic 750 are transported over the same PW. 752 Ethernet OAM for E-Tree including both service OAM and segment OAM 753 frames shall undergo the same VLAN mapping as the data traffic; and 754 root VLAN SHOULD be applied to segment OAM frames so that they are 755 not filtered. 757 8. Applicability 759 The solution is applicable to both LDP VPLS [RFC4762] and BGP VPLS 760 [RFC4761]. 762 The solution is applicable to both "VPLS Only" networks and VPLS with 763 Ethernet aggregation networks. 765 The solution is also applicable to PBB VPLS networks. 767 9. Security Considerations 769 Besides security considerations as described in [RFC4448], [RFC4761] 770 and [RFC4762], this solution prevents leaf to leaf communication in 771 the data plane of VPLS when its PEs are interconnected with PWs. In 772 this regard, security can be enhanced for customers with this 773 solution. 775 10. IANA Considerations 777 IANA is requested to allocate a value for E-Tree in the registry of 778 Pseudowire Interface Parameters Sub-TLV type. 780 Parameter ID Length Description 781 ======================================= 782 TBD 8 E-Tree 784 IANA is requested to allocate two new LDP status codes from the 785 registry of name "STATUS CODE NAME SPACE". The following values are 786 suggested: 788 Range/Value E Description 789 ------------- ----- ---------------------- 790 TBD 1 E-Tree VLAN mapping not supported 791 TBD 0 Leaf to Leaf PW released 793 IANA is requested to allocate a value for E-Tree in the registry of 794 BGP Extended Community. 796 Type Value Name 797 ======================================= 798 TBD E-Tree Info 800 11. References 802 11.1. Normative References 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, March 1997. 807 [RFC4447] Martini, L., and et al, "Pseudowire Setup and Maintenance 808 Using Label Distribution Protocol (LDP)", RFC 4447, April 809 2006. 811 [RFC4448] Martini, L., and et al, "Encapsulation Methods for 812 Transport of Ethernet over MPLS Networks", RFC 4448, April 813 2006. 815 [RFC4761] Kompella, K. and Rekhter, Y., "Virtual Private LAN Service 816 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 817 4761, January 2007 819 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN 820 Services using LDP", RFC 4762, January 2007. 822 [RFC6136] Sajassi, A. and Mohan, D., "L2VPN OAM Requirements and 823 Framework", RFC 6136, March 2011 825 11.2. Informative References 827 [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to- 828 Edge (PWE3) Architecture", RFC 3985, March 2005. 830 [RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2 831 Virtual Private Networks (L2VPNs)", RFC 4664, September 832 2006. 834 [RFC6246] Sajassi, A., and et al, "Virtual Private LAN Service (VPLS) 835 Interoperability with Customer Edge (CE) Bridges", RFC 6246, 836 June 2011 838 [ETree-req] Key, R., et al, "Requirements for MEF E-Tree Support in 839 VPLS", draft-ietf-l2vpn-etree-reqt-01, Work in Progress 841 [Vpls-etree] Key, R., and et al, "Extension to VPLS for E-Tree", 842 draft-key-l2vpn-vpls-etree-06, October 2011 844 [802.1aq] IEEE 802.1aq D4.3, Virtual Bridged Local Area Networks - 845 Amendment 9: Shortest Path Bridging, September 2011 847 [Etree-2PW] Ram, R., and et al., Extension to LDP-VPLS for E-Tree 848 Using Two PW, draft-ram-l2vpn-ldp-vpls-etree-2pw-02, May 849 2011 851 [PBB-VPLS] Balus, F., and et al., Extensions to VPLS PE model for 852 Provider Backbone Bridging, draft-ietf-l2vpn-pbb-vpls-pe- 853 model-04, October 2011 855 12. Acknowledgments 857 The authors would like to thank Adrian Farrel, Susan Hares and Shane 858 Amante for their valuable advices, thank Ben Mack-crane, Edwin 859 Mallette, Donald Fedyk, Dave Allan, Giles Heron, Raymond Key, Josh 860 Rogers, Sam Cao and Daniel Cohn for their valuable comments and 861 discussions. 863 Appendix A. Other PE Models for E-Tree 865 A.1. A PE Model With a VSI and No bridge 867 If there is no bridge module in a PE, the PE may consist of Native 868 Service Processors (NSPs) as shown in Figure A.1 (adapted from Fig. 5 869 of [RFC3985]) where any transformation operation for VLANs (e.g., 870 VLAN insertion/removal or VLAN mapping) may be applied. Thus a root 871 VLAN or leaf VLAN can be added by the NSP depending on the UNI type 872 (root/leaf) associated with the AC over which the packet arrives. 874 Further, when a packet with a leaf VLAN exits a forwarder and arrives 875 at the NSP, the NSP must drop the packet if the egress AC is 876 associated with a leaf UNI. 878 Tagged PW and VLAN mapping work in the same way as in the typical PE 879 model. 881 +----------------------------------------+ 882 | PE Device | 883 Multiple+----------------------------------------+ 884 AC | | | Single | PW Instance 885 <------>o NSP # + PW Instance X<----------> 886 | | | | 887 |------| VSI |----------------------| 888 | | | Single | PW Instance 889 <------>o NSP #Forwarder + PW Instance X<----------> 890 | | | | 891 |------| |----------------------| 892 | | | Single | PW Instance 893 <------>o NSP # + PW Instance X<----------> 894 | | | | 895 +----------------------------------------+ 897 Figure A.1 A PE model with a VSI and no bridge module 899 This PE model may be used by an MTU-s in an H-VPLS network, or an N- 900 PE in an H-VPLS network with non-bridging edge devices, wherein a 901 spoke PW can be treated as an AC in this model. 903 A.2. A PE Model With external E-Tree interface 905 +----------------------------------------+ 906 | PE Device | 907 Root +----------------------------------------+ 908 VLAN | | Single | PW Instance 909 <------>o + PW Instance X<----------> 910 | | | 911 | VSI |----------------------| 912 | | Single | PW Instance 913 | Forwarder + PW Instance X<----------> 914 | | | 915 Leaf | |----------------------| 916 VLAN | | Single | PW Instance 917 <------>o + PW Instance X<----------> 918 | | | 919 +----------------------------------------+ 921 Figure A.2 A PE model with external E-Tree interface 923 A more simplified PE model is depicted in A.2, where Root/Leaf VLANs 924 are directly or indirectly over a single PW connected to a same VSI 925 forwarder in a PE, any transformation of E-Tree VLANs, e.g., VLAN 926 insertion/removal or VLAN mapping, can be performed by some outer 927 equipments, and the PE may further translate these VLANs into its own 928 local VLANs. This PE model may be used by an N-PE in an H-VPLS 929 network with bridging-capable devices, or scenarios such as providing 930 E-Tree Network-to-Network (NNI) interfaces. 932 Authors' Addresses 934 Yuanlong Jiang 935 Huawei Technologies Co., Ltd. 936 Bantian, Longgang district 937 Shenzhen 518129, China 938 Email: jiangyuanlong@huawei.com 940 Lucy Yong 941 Huawei USA 942 1700 Alma Dr. Suite 500 943 Plano, TX 75075, USA 944 Email: lucyyong@huawei.com 946 Manuel Paul 947 Deutsche Telekom 948 Winterfeldtstr. 21 949 10781 Berlin, Germany 950 Email: manuel.paul@telekom.de 952 Frederic Jounay 953 Orange CH 954 4 rue caudray 1020 Renens, Switzerland 955 Email: frederic.jounay@orange.ch 957 Florin Balus 958 Alcatel-Lucent 959 701 E. Middlefield Road 960 Mountain View, CA, USA 94043 961 Email: florin.balus@alcatel-lucent.com 963 Wim Henderickx 964 Alcatel-Lucent 965 Copernicuslaan 50 966 2018 Antwerp, Belgium 967 Email: wim.henderickx@alcatel-lucent.com 969 Ali Sajassi 970 Cisco 971 170 West Tasman Drive 972 San Jose, CA 95134, USA 973 Email: sajassi@cisco.com