idnits 2.17.1 draft-ietf-l2vpn-vpls-pe-etree-04.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 (September 30, 2014) is 3468 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 858, but no explicit reference was found in the text == Unused Reference: 'ETree-frwk' is defined on line 862, 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 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: March 2015 September 30, 2014 20 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) 21 draft-ietf-l2vpn-vpls-pe-etree-04.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 30, 2015. 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. 277 Therefore, the association between an AC port and a PW on a VSI is 278 difficult, sometimes even impossible. 280 This model could be further enhanced: When Ethernet frames arrive at 281 a PE, a root VLAN or a leaf VLAN tag is added. Then the frames with 282 the root VLAN tag are transmitted both to the roots and the leaves, 283 while the frames with the leaf VLAN tag are transmitted to the roots 284 but dropped for the leaves (these VLAN tags are removed before the 285 frames are transmitted over the wire). It was demonstrated in 286 [802.1Q-2011] that the E-Tree service in Ethernet networks can be 287 well supported with this mechanism. 289 Assuming this mechanism is implemented in the bridge module, it is 290 quite straightforward to infer a VPLS PE model with two VSIs to 291 support the E-Tree (as shown in Fig. 3). But this model will require 292 two VSIs per PE and two sets of PWs per E-Tree service, which is 293 poorly scalable in a large MPLS/VPLS network; in addition, both these 294 VSIs have to share their learned MAC addresses. 296 +----------------------------------------+ 297 | VPLS-capable PE model | 298 | +---------------+ +------+ | 299 | | | |VSI-1 |------------ 300 | | |==========| |------------ PWs 301 | | Bridge ------------ |------------ 302 | | | Root +------+ | 303 | | Module | S-VLAN | 304 | | | | 305 | | (802.1ad | | 306 | | bridge) | | 307 | | | Leaf | 308 | | | S-VLAN +------+ | 309 | | ------------VSI-2 |------------- 310 | | |==========| |------------- PWs 311 | | | ^ | |------------- 312 | +---------------+ | +------+ | 313 | | | 314 +-------------------------|--------------+ 315 LAN emulation Interface 317 Figure 3 A VPLS PE Model for E-Tree with 2 VSIs 319 4.2. A New PE Model with E-Tree Support 321 In order to support the E-Tree in a more scalable way, a new VPLS PE 322 model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is 323 proposed. As depicted in Fig. 4, the bridge module is connected to 324 the T-VSI with a dual-VLAN virtual interface, i.e., both the root 325 VLAN and the leaf VLAN are connected to the same T-VSI, and they 326 share the same FIB and work in shared VLAN learning. In this way, 327 only one VPLS instance and one set of PWs is needed per E-Tree 328 service, and the scalability of VPLS is improved. 330 +----------------------------------------+ 331 | VPLS-capable PE model | 332 | +---------------+ +------+ | 333 | | |==========|TVSI-1|------------ 334 +---+AC | | ------------ |------------ PWs 335 |CE |-------| Bridge ------------ |------------ 336 +---+ | | | Root & +------+ | 337 | | Module | Leaf VLAN o | 338 | | | o | 339 | | | o | 340 | | | o | 341 | | | o | 342 +---+AC | | | VLAN-n +------+ | 343 |CE |-------| ------------VSI-n |------------- 344 +---+ | | |==========| |------------- PWs 345 | | | ^ | |------------- 346 | +---------------+ | +------+ | 347 | | | 348 +-------------------------|--------------+ 349 LAN emulation Interface 351 Figure 4 A VPLS PE Model for E-Tree with a Single T-VSI 353 For an untagged port (frames over this port are untagged) or VLAN- 354 unaware port (VLAN tags in the frames are ignored), the Ethernet 355 frames received from the root ACs SHOULD be tagged with a root C-VLAN, 356 and optionally MAY be added with another root S-VLAN. 358 For a C-VLAN tagged port, the Ethernet frames received from the root 359 ACs SHOULD be added with a root S-VLAN. 361 For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames 362 received from the root ACs SHOULD be translated to the root S-VLAN in 363 the VPLS network domain. Alternatively, the PBB VPLS PE model (where 364 an IEEE 802.1ah bridge module is embedded in the PE) as described in 365 [PBB-VPLS] MAY be used, and a root B-VLAN or leaf B-VLAN MAY be added 366 in this case (the E-Tree attribute may also be indicated with two I- 367 SID tags in the bridge module, and the frames are further 368 encapsulated and transported transparently over a single B-VLAN, thus 369 the PBB VPLS works just in the same way as described in [PBB-VPLS] 370 and will be discussed no more in this document). When many S-VLANs 371 are multiplexed in a single AC, the 2nd option has an advantage of 372 both VLAN scalability and MAC address scalability. 374 In a similar way, the traffic from the leaf ACs is tagged and 375 transported on the leaf C-VLAN, S-VLAN or B-VLAN. 377 In all cases, the outermost VLAN in the resulted Ethernet header is 378 used to indicate the E-Tree attribute of an Ethernet frame; this 379 document will use VLAN to refer to this outermost VLAN for simplicity 380 in the latter sections. 382 5. PW for E-Tree Support 384 5.1. PW Encapsulation 386 To support an E-Tree service, T-VSIs in a VPLS must be interconnected 387 with a bidirectional Ethernet PW. The Ethernet PW may work in the 388 tagged mode (PW type 0x0004) as described in [RFC4448], and a VLAN 389 tag must be carried in each frame in the PW to indicate the frame 390 originated from either root or leaf (the VLAN tag indicating the 391 frame originated from either root or leaf can be translated by a 392 bridge module in the PE or added by an outside Ethernet edge device, 393 even by a customer device). In the tagged PW mode, two service 394 delimiting VLANs must be allocated in the VPLS domain for an E-Tree. 395 PW processing for the tagged PW will be described in Section 5.3 of 396 this document. 398 Raw PW (PW type 0x0005 in [RFC4448]) may be used to carry E-Tree 399 service for a PW in Compatible mode as shown in Section 5.3.2. 401 5.2. VLAN Mapping 403 There are two ways of manipulating VLANs for an E-Tree in VPLS: 405 o Global VLAN based, that is, provisioning two global VLANs (Root 406 VLAN, Leaf VLAN) across the VPLS network, thus no VLAN mapping is 407 needed at all, or the VLAN mapping is done completely in the 408 Ethernet domains. 410 o Local VLAN based, that is, provisioning two local VLANs for each 411 PE (which participates in the E-Tree) in the VPLS network 412 independently. 414 The first method requires no VLAN mapping in the PW, but two unique 415 service delimiting VLANs must be allocated across the VPLS domain. 417 The second method is more scalable in the use of VLANs, but needs a 418 VLAN mapping mechanism in the PW similar to what is already described 419 in Section 4.3 of [RFC4448]. 421 Global or local VLANs can be manually configured or provisioned by an 422 OSS system. Alternatively, some automatic VLAN allocation algorithm 423 may be provided in the management plane, but it is out scope of this 424 document. 426 For both methods, VLAN mapping parameters from a remote PE can be 427 provisioned or determined by a signaling protocol as described in 428 Section 6 when a PW is being established. 430 5.3. PW Processing 432 5.3.1.PW Processing in the VLAN Mapping Mode 434 In the VLAN Mapping mode, two VPLS PEs with E-Tree capability are 435 inter-connected with a PW (For example, the scenario of Fig. 5 436 depicts the interconnection of two PEs miscellaneously attached with 437 both root and leaf nodes). 439 +------------------------+ 440 | VPLS PE with T-VSI | 441 | | 442 +----+ | +------+ +-----+ | PW 443 |Root|------| VLAN |-------|T-VSI|---------- 444 +----+ | | BRG | | |---------- 445 +----+ | | |-------| |---------- 446 |Leaf|------| | | |---------+ 447 +----+ | +------+ +-----+ | | 448 | | | 449 +------------------------+ | 450 | 451 +------------------------+ | 452 | VPLS PE with T-VSI | | 453 | | | 454 +----+ | +------+ +-----+ | PW | 455 |Root|------| VLAN |-------|T-VSI|---------+ 456 +----+ | | BRG | | |---------- 457 +----+ | | |-------| |---------- 458 |Leaf|------| | | |---------- 459 +----+ | +------+ +-----+ | 460 | | 461 +------------------------+ 463 Figure 5 T-VSI Interconnected in the Normal Mode 465 If a PE is in the VLAN mapping mode for a PW, then in the data plane 466 the PE MUST map the VLAN in each frame as follows: 468 o Upon transmitting frames on the PW, map from local VLAN to remote 469 VLAN (i.e., the local leaf VLAN in a frame is translated to the 470 remote leaf VLAN; the local root VLAN in a frame is translated to the 471 remote root VLAN). 473 o Upon receiving frames on the PW, map from remote VLAN to local VLAN, 474 and the frames are further forwarded or dropped in the egress bridge 475 module using the filtering mechanism as described in [802.1Q-2011]. 477 The signaling for VLANs used by E-Tree is specified in Section 6. 479 5.3.2.PW Processing in the Compatible Mode 481 The new VPLS PE model can work in a traditional VPLS network 482 seamlessly in the compatibility mode. As shown in Fig. 6, the VPLS PE 483 with T-VSI can be attached with root and/or leaf nodes, while the 484 VPLS PE with a traditional VSI can only be attached with root nodes. 485 A raw PW should be used to connect them. 487 +------------------------+ 488 | VPLS PE with T-VSI | 489 | | 490 +----+ | +------+ +-----+ | PW 491 |Root|------| VLAN |-------|T-VSI|---------- 492 +----+ | | BRG | | |---------- 493 +----+ | | |-------| |---------- 494 |Leaf|------| | | |---------+ 495 +----+ | +------+ +-----+ | | 496 | | | 497 +------------------------+ | 498 | 499 +------------------------+ | 500 | VPLS PE with VSI | | 501 | | | 502 +----+ | +------+ +-----+ | PW | 503 |Root|------| VLAN |-------|VSI |---------+ 504 +----+ | | BRG | | |---------- 505 +----+ | | | | |---------- 506 |Root|------| | | |---------- 507 +----+ | +------+ +-----+ | 508 | | 509 +------------------------+ 511 Figure 6 T-VSI interconnected with Traditional VSI 513 If a PE is in the Compatible mode for a PW, then in the data plane 514 the PE MUST process the frame as follows: 516 o Upon transmitting frames on the PW, remove the root or leaf VLAN in 517 the frames. 519 o Upon receiving frames on the PW, add a VLAN tag with a value of the 520 local root VLAN to the frames. 522 5.3.3.PW Processing in the Optimized Mode 524 When two PEs (both have E-Tree capability) are inter-connected and 525 one of them (e.g., PE2) is attached with only leaf nodes, as shown in 526 the scenario of Fig. 7, its peer PE (e.g., PE1) should then work in 527 the optimized mode. In this case, PE1 should not send the frames 528 originated from the local leaf VLAN to PE2, i.e., these frames are 529 dropped rather than transported over the PW. The bandwidth efficiency 530 of the VPLS can thus be improved. The signaling for the PE attached 531 with only leaf nodes is specified in Section 6. 532 +------------------------+ 533 |VPLS PE with T-VSI (PE1)| 534 | | 535 +----+ | +------+ +-----+ | PW 536 |Root|------| VLAN |-------|T-VSI|---------- 537 +----+ | | BRG | | |---------- 538 +----+ | | |-------| |---------- 539 |Leaf|------| | | |---------+ 540 +----+ | +------+ +-----+ | | 541 | | | 542 +------------------------+ | 543 | 544 +------------------------+ | 545 |VPLS PE with T-VSI (PE2)| | 546 | | | 547 +----+ | +------+ +-----+ | PW | 548 |Leaf|------| VLAN |-------|T-VSI|---------+ 549 +----+ | | BRG | | |---------- 550 +----+ | | |-------| |---------- 551 |Leaf|------| | | |---------- 552 +----+ | +------+ +-----+ | 553 | | 554 +------------------------+ 556 Figure 7 T-VSI interconnected with PE attached with only leaf nodes 558 If a PE is in the Optimized Mode for a PW, upon transmit, the PE 559 SHOULD first operate as follows: 561 o Drop a frame if its VLAN ID matches the local leaf VLAN ID. 563 6. Signaling for E-Tree Support 565 6.1. LDP Extensions for E-Tree Support 567 In addition to the signaling procedures as specified in [RFC4447], 568 this document proposes a new interface parameter sub-TLV to provision 569 an E-Tree service and negotiate the VLAN mapping function, as follows: 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | E-Tree | Length=8 | Reserved |P|V| 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Root VLAN ID | Leaf VLAN ID | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Figure 8 E-Tree Sub-TLV 580 Where: 582 o E-Tree is the sub-TLV identifier to be assigned by IANA. 584 o Length is the length of the sub TLV in octets. 586 o Reserved bits MUST be set to zero on transmit and be ignored on 587 receive. 589 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 590 attached with only leaf nodes, and set to 0 otherwise. 592 o V is a bit indicating the sender's VLAN mapping capability. A PE 593 capable of VLAN mapping MUST set this bit, and clear it otherwise. 595 o Root VLAN ID is the value of the local root VLAN. 597 o Leaf VLAN ID is the value of the local leaf VLAN. 599 When setting up a PW for the E-Tree based VPLS, two PEs negotiate the 600 E-Tree support using the above E-Tree sub-TLV. Note PW type of 0x0004 601 should be used during the PW negotiation. 603 A PE that wishes to support E-Tree service MUST include an E-Tree 604 Sub-TLV in its PW label mapping message and include its local root 605 VLAN ID and leaf VLAN ID in the TLV. A PE that has the VLAN mapping 606 capability MUST set the V bit to 1, and a PE is attached with only 607 leaf nodes SHOULD set the P bit to 1. 609 In default, for each PW, VLAN-Mapping-Mode, Compatible-Mode, and 610 Optimized-Mode are all set to FALSE. 612 A PE that receives a PW label mapping message with an E-Tree Sub-TLV 613 from its peer PE, after saving the VLAN information for the PW, must 614 process it as follows: 616 1) if the root and leaf VLAN ID in the message match the local root 617 and leaf VLAN ID, then continue to 3); 619 2) else { 621 if the bit V is cleared, then { 623 if the PE is capable of VLAN mapping, then it MUST set 624 VLAN-Mapping-Mode to TRUE; 626 else { 628 A label release message with the error code "E-Tree 629 VLAN mapping not supported" is sent to the peer PE 630 and exit the process; 632 } 634 } 636 if the bit V is set, and the PE is capable of VLAN mapping, 637 then the PE with the minimum IP address MUST set VLAN-Mapping- 638 Mode to TRUE; 640 } 642 3) If the P bit is set, then: 644 { 646 If the PE is a leaf-only node itself, then a label release 647 message with a status code "Leaf to Leaf PW released" is sent to 648 the peer PE and exit the process; 650 Else the PE SHOULD set the Optimized-Mode to TRUE. 652 } 654 If a PE has sent an E-Tree Sub-TLV but does not receive any E-Tree 655 Sub-TLV in its peer's PW label mapping message, The PE SHOULD then 656 establish a raw PW with this peer as in traditional VPLS and set 657 Compatible-Mode to TRUE for this PW. 659 Data plane processing for this PW is as following: 661 If Optimized-Mode is TRUE, then data plane processing as described in 662 Section 5.3.3 applies. 664 If VLAN-Mapping-Mode is TRUE, then data plane processing as described 665 in Section 5.3.1 applies. 667 If Compatible-Mode is TRUE, then data plane processing is as 668 described in Section 5.3.2. 670 PW processing as described in [RFC4448] proceeds as usual for all 671 cases. 673 6.2. BGP Extensions for E-Tree Support 675 A new E-Tree extended community is proposed for E-Tree signaling in 676 BGP VPLS: 678 +------------------------------------+ 679 | Extended community type (2 octets) | 680 +------------------------------------+ 681 | Root VLAN (2 octets) | 682 +------------------------------------+ 683 | Leaf VLAN (2 octets) | 684 +------------------------------------+ 685 | Reserved |P|V| 686 +------------------------------------+ 688 Figure 9 E-Tree Extended Community 690 Where: 692 o Root VLAN ID is the value of the local root VLAN. 694 o Leaf VLAN ID is the value of the local leaf VLAN. 696 o Reserved, 14 bits MUST be set to zero on transmit and be ignored 697 on receive. 699 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 700 attached with only leaf nodes, and set to 0 otherwise. 702 o V is a bit indicating the sender's VLAN mapping capability. A PE 703 capable of VLAN mapping MUST set this bit, and clear it otherwise. 705 The PEs attached with both leaf and root nodes MUST support BGP E- 706 Tree signaling as described in this document, and SHOULD support VLAN 707 mapping in their data planes. The traditional PE attached with only 708 root nodes may also participate in an E-Tree service. If some PEs 709 don't support VLAN mapping, global VLANs as per Section 5.2 MUST be 710 provisioned for an E-Tree service. 712 In BGP VPLS signaling, besides attaching a Layer2 Info Extended 713 Community as detailed in [RFC4761], an E-Tree Extended Community MUST 714 be further attached if a PE wishes to participate in an E-Tree 715 service. The PE MUST include its local root VLAN ID and leaf VLAN ID 716 in the E-Tree Extended Community. A PE attached with only leaf nodes 717 of an E-Tree SHOULD set the P bit in the E-Tree Extended Community to 718 1. 720 A PE that receives a BGP UPDATE message with an E-Tree Extended 721 Community from its peer PE, after saving the VLAN information for the 722 PW, must process it as follows (after processing procedures as 723 specified in Section 3.2 of [RFC4761]): 725 1) if the root and leaf VLAN ID in the E-Tree Extended Community 726 match the local root and leaf VLAN ID, then continue to 3); 728 2) else { 730 if the bit V is cleared, then { 732 if the PE is capable of VLAN mapping, then it MUST set 733 VLAN-Mapping-Mode to TRUE; 735 else { 737 Log with a message "E-Tree VLAN mapping not 738 supported" and exit the process; 740 } 742 if the bit V is set, and the PE is capable of VLAN mapping, 743 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 744 to TRUE; 746 } 748 3) If the P bit is set { 749 If the PE is a leaf-only PE itself, then forbids any traffic on 750 the PW; 752 Else the PE SHOULD set the Optimized-Mode to TRUE. 754 } 756 A PE which does not recognize this attribute shall ignore it silently. 757 If a PE has sent an E-Tree Extended Community but does not receive 758 any E-Tree Extended Community from its peer, the PE SHOULD then 759 establish a raw PW with this peer as in traditional VPLS, and set 760 Compatible-Mode to TRUE for this PW. 762 Data plane in the VPLS is the same as described in Section 4.2 of 763 [RFC4761], and data plane processing for a PW is the same as 764 described at the end of Section 6.1. 766 7. OAM Considerations 768 VPLS OAM requirements and framework as specified in [RFC6136] are 769 applicable to E-Tree, as both Ethernet OAM frames and data traffic 770 are transported over the same PW. 772 Ethernet OAM for E-Tree including both service OAM and segment OAM 773 frames shall undergo the same VLAN mapping as the data traffic; and 774 root VLAN SHOULD be applied to segment OAM frames so that they are 775 not filtered. 777 8. Applicability 779 The solution is applicable to both LDP VPLS [RFC4762] and BGP VPLS 780 [RFC4761]. 782 The solution is applicable to both "VPLS Only" networks and VPLS with 783 Ethernet aggregation networks. 785 The solution is also applicable to PBB VPLS networks. 787 9. Security Considerations 789 Besides security considerations as described in [RFC4448], [RFC4761] 790 and [RFC4762], this solution prevents leaf to leaf communication in 791 the data plane of VPLS when its PEs are interconnected with PWs. In 792 this regard, security can be enhanced for customers with this 793 solution. 795 10. IANA Considerations 797 IANA is requested to allocate a value for E-Tree in the registry of 798 Pseudowire Interface Parameters Sub-TLV type. 800 Parameter ID Length Description 801 ======================================= 802 TBD 8 E-Tree 804 IANA is requested to allocate two new LDP status codes from the 805 registry of name "STATUS CODE NAME SPACE". The following values are 806 suggested: 808 Range/Value E Description 809 ------------- ----- ---------------------- 810 TBD 1 E-Tree VLAN mapping not supported 811 TBD 0 Leaf to Leaf PW released 813 IANA is requested to allocate a value for E-Tree in the registry of 814 BGP Extended Community. 816 Type Value Name 817 ======================================= 818 TBD E-Tree Info 820 11. References 822 11.1. Normative References 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, March 1997. 827 [RFC4447] Martini, L., and et al, "Pseudowire Setup and Maintenance 828 Using Label Distribution Protocol (LDP)", RFC 4447, April 829 2006. 831 [RFC4448] Martini, L., and et al, "Encapsulation Methods for 832 Transport of Ethernet over MPLS Networks", RFC 4448, April 833 2006. 835 [RFC4761] Kompella, K. and Rekhter, Y., "Virtual Private LAN Service 836 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 837 4761, January 2007 839 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN 840 Services using LDP", RFC 4762, January 2007. 842 [RFC6136] Sajassi, A. and Mohan, D., "L2VPN OAM Requirements and 843 Framework", RFC 6136, March 2011 845 11.2. Informative References 847 [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to- 848 Edge (PWE3) Architecture", RFC 3985, March 2005. 850 [RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2 851 Virtual Private Networks (L2VPNs)", RFC 4664, September 852 2006. 854 [RFC6246] Sajassi, A., and et al, "Virtual Private LAN Service (VPLS) 855 Interoperability with Customer Edge (CE) Bridges", RFC 6246, 856 June 2011 858 [ETree-req] Key, R., et al, "Requirements for Metro Ethernet Forum 859 (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual 860 Private Network (L2VPN)", RFC 7152, March 2014 862 [ETree-frwk] Key, R., and et al, "A Framework for E-Tree Service over 863 MPLS Network", draft-ietf-l2vpn-etree-frwk-10, Work in 864 Progress 866 [802.1Q-2011] IEEE 802.1Q, Media Access Control (MAC) Bridges and 867 Virtual Bridge Local Area Networks, August 2011 869 [PBB-VPLS] Balus, F., and et al., Extensions to VPLS PE model for 870 Provider Backbone Bridging, RFC 7041, November 2013 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