idnits 2.17.1 draft-ram-l2vpn-ldp-vpls-etree-2pw-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2011) is 4727 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Ram, Orckit-Corrigent 2 Internet Draft D. Cohn, Orckit-Corrigent 3 Category: Standard Track R. Key, Telstra 4 P. Agarwal, Broadcom 5 Expires: November 18, 2011 May 18, 2011 7 Extension to LDP-VPLS for E-Tree Using Two PW 8 draft-ram-l2vpn-ldp-vpls-etree-2pw-02.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may not be modified, 17 and derivative works of it may not be created, and it may not be 18 published except as an Internet-Draft. 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, except to publish it 23 as an RFC and to translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire in November 2011. 43 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. 54 Abstract 56 This document proposes a solution for Metro Ethernet Forum (MEF) 57 Ethernet Tree (E-Tree) support in Virtual Private LAN Service using 58 LDP Signaling (LDP-VPLS) [RFC4762]. The proposed solution is 59 characterized by the use of two PWs between a pair of PEs. This 60 solution is applicable for both VPLS and H-VPLS. 62 Table of Contents 64 1. Introduction ................................................... 3 65 2. Conventions used in this document............................... 3 66 3. The Problem .................................................... 3 67 4. The 2-PW Solution .............................................. 4 68 5. Extension to VPLS for E-Tree.................................... 5 69 5.1. AC E-Tree Type ......................................... 5 70 5.2. VSI E-Tree Type and Identifier.......................... 5 71 5.2.1. VSI E-Tree Type Encoding........................... 5 72 5.2.2. VSI E-Tree Identifier Encoding..................... 6 73 5.3. Additional Filtering in Data Forwarding................. 6 74 5.4. Root/Leaf PWs Signaling................................. 7 75 5.5. Supporting Remote AC.................................... 7 76 6. Backward Compatibility ......................................... 8 77 7. Compliance with Requirements.................................... 8 78 8. Security Considerations......................................... 8 79 9. IANA Considerations ............................................ 8 80 10. Acknowledgements .............................................. 8 81 11. References .................................................... 9 82 11.1. Normative References................................... 9 83 11.2. Informative References................................. 9 85 1. Introduction 87 This document proposes a solution for Metro Ethernet Forum (MEF) 88 Tree (E-Tree) support in Virtual Private LAN Service using LDP 89 Signaling (LDP-VPLS) [RFC4762]. 91 [Draft ETree VPLS Req] is used as requirement specification. 93 The proposed solution is characterized by the use of two PWs between 94 a pair of PEs, which requires extension to the current VPLS standard 95 [RFC4762]. 97 This solution is applicable for both VPLS and H-VPLS. 99 The proposed solution is composed of three main components: 101 - Current standard LDP-VPLS [RFC4762] 102 - Extension to LDP-VPLS specified in this document 103 - PE local split horizon mechanism 105 2. Conventions used in this document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC-2119 [RFC2119]. 111 In this document, these words will appear with that interpretation 112 only when in ALL CAPS. Lower case uses of these words are not to be 113 interpreted as carrying RFC-2119 significance. 115 3. The Problem 117 [Draft ETree VPLS Req] identifies the problem when there are two or 118 more PEs with both Root AC and Leaf AC. 120 <-----------E-Tree----------> 122 +---------+ +---------+ 123 | PE1 | | PE2 | 124 +---+ | +---+ | | +---+ | +---+ 125 |CE1+----AC1----+--+ | | | | +--+----AC3----+CE3| 126 +---+ (Root AC) | | V | | | | V | | (Root AC) +---+ 127 | | S +--+--PW----+--+ S | | 128 +---+ | | I | | | | I | | +---+ 129 |CE2+----AC2----+--+ | | | | +--+----AC4----+CE4| 130 +---+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +---+ 131 +---------+ +---------+ 133 Figure 1: Problem Scenario for Leaf-to-Leaf Communication 134 Restriction 136 When PE2 receives a frame from PE1 via the Ethernet PW, 137 - PE2 does not know whether the ingress AC is a Leaf AC or not 138 - PE2 does not have sufficient information to enforce the Leaf- 139 to-Leaf communication restriction 141 4. The 2-PW Solution 143 A simple fix is to carry additional information with each frame on 144 the PW, indicating whether the frame is originated from a Leaf AC or 145 a Root AC on the ingress PE. 147 The proposed solution uses a pair of PWs to interconnect two VPLS 148 PEs: 150 o First PW is used for frames originated from Root ACs 152 o Second PW is used for frames originated from Leaf ACs 154 <--------------E-Tree--------------> 155 +---------+ +---------+ 156 | PE1 | | PE2 | 157 +---+ | +---+ | | +---+ | +---+ 158 |CE1+----AC1----+--+ | | | | +--+----AC3----+CE3| 159 +---+ (Root AC) | | V +--+-VSI Root PW -+--+ V | | (Root AC) +---+ 160 | | S | | | | S | | 161 +---+ | | I +--+-VSI Leaf PW -+--+ I | | +---+ 162 |CE2+----AC2----+--+ | | | | +--+----AC4----+CE4| 163 +---+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +---+ 164 +---------+ +---------+ 166 Figure 2: Two-PW Solution for Leaf-to-Leaf Communication Restriction 167 Extension to current VPLS standard [RFC4762] is required. 169 5. Extension to VPLS for E-Tree 171 5.1. AC E-Tree Type 173 Each AC connected to a specific VPLS instance on a PE MUST have an 174 AC E-Tree Type attribute, either Leaf AC or Root AC. For backward 175 compatibility, the default AC E-Tree Type MUST be Root. 177 This AC E-Tree Type is locally configured on a PE and no signaling 178 is required between PEs. 180 5.2. VSI E-Tree Type and Identifier 182 Two new PW interface parameters (as defined in section 5.5 of 183 [RFC4447]) are defined for use in E-Tree VPLS: VSI E-Tree type and 184 VSI E-Tree identifier. 186 VSI E-Tree type can be either root or leaf and identifies VSI root 187 PW and VSI leaf PW respectively, as defined in section 4. 189 VSI E-tree identifier is a number that is used to identify a pair of 190 root and leaf PW as part of the same logical VSI interface. 192 On reception, the two PWs SHALL be handled as the same logical VSI 193 interface with respect to MAC address learning/forwarding, e.g. 194 traffic SHALL NOT be forwarded between such PWs and MAC addresses 195 arriving at one of the PWs SHALL be learned with a common logical 196 VSI interface. 198 On transmission, the VPLS processing entity SHALL send root- 199 originated traffic via the root PW, and SHALL send leaf-originated 200 traffic via the leaf PW. 202 The pair SHALL be unique in 203 PWs connecting a pair of VPLS PEs. 205 5.2.1. VSI E-Tree Type Encoding 207 The VSI E-Tree type field is encoded as an interface parameters sub- 208 TLV (as defined in section 5.5 of [RFC4447]). 210 The field structure is defined as follows: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Type (TBD) | Length (1) | VSI E-Tree Type | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 VSI E-tree Type can take the following values: 220 0 E-Tree Root VSI 222 1 E-Tree Leaf VSI 224 5.2.2. VSI E-Tree Identifier Encoding 226 The VSI E-Tree identifier field is encoded as an interface 227 parameters sub-TLV (as defined in section 5.5 of [RFC4447]). 229 The field structure is defined as follows: 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Type (TBD) | Length (1) | VSI E-Tree Identifier | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | VSI E-Tree Identifier(cont.) | Reserved | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 VSI E-tree Identifier is a 32-bit number that is used to identify a 240 pair of root and leaf PW as part of the same logical VSI interface, 241 in the context of a pair of VPLS PEs. 243 The reserved field SHALL be set to zero. 245 5.3. Additional Filtering in Data Forwarding 247 An egress PE SHALL NOT deliver a frame originated at a leaf AC to 248 another leaf AC. 250 The following specifies how AC E-Tree type per frame is determined: 252 o A frame received from a root PW indicates that the frame was 253 originated from a root AC 255 o A frame received from a leaf PW indicates that the frame was 256 originated from a leaf AC. 258 o For the case where both ingress AC and egress AC are on the 259 same PE, local split horizon implementation on the PE will be 260 sufficient, and is not further discussed in this document. 262 5.4. Root/Leaf PWs Signaling 264 Signaling of root and leaf PWs is required only when two PWs are 265 used for interconnecting between pair of VSIs. As explained in 266 section . 5.2. : 268 o Root VSI E-Tree type SHALL be used to signal a root PW. 270 o Leaf VSI E-Tree type be used to signal a leaf PW. 272 PW type signaling rules remain as defined in [RFC4447]. 274 5.5. Supporting Remote AC 276 When PW is used to interconnect between VSI and a remote AC (e.g. 277 the PW1, PW2 in Figure 3), an Ethernet Raw or Ethernet tagged PW 278 types SHALL be used as defined in [RFC4762]. 280 <----------------------E-Tree----------> 281 +-------+ +-------+ 282 +----+ | PE1 | | PE2 | 283 +---+ | | | +---+ | | +---+ | 284 |CE1+---AC1---+----+PW1-+-+ | | | | | | +---+ 285 +---+(Root AC)| | | | | | | | +-+---AC4---+CE4| 286 |PE-r| | | V +-+VSI Root PW-+-+ V | |(Root AC)+---+ 287 +---+ | | | | | | | | | | 288 |CE2+---AC2---+----+PW2-+-+ S | | | | S | | 289 +---+(Leaf AC)| | | | | | | | | | 290 +----+ | | I +-+VSI Leaf PW-+-+ I | | 291 +---+ | | | | | | | | +---+ 292 |CE3+--------AC3--------+-+ | | | | +-+---AC5---+CE5| 293 +---+ (Leaf AC) | +---+ | | +---+ |(Leaf AC)+---+ 294 +-------+ +-------+ 296 Figure 3: VPLS with Remote AC Connectivity 298 In addition, the AC type i.e. Root or leaf, SHALL be locally 299 provisioned on the VSI side to specify the remote AC E-Tree Type per 300 PW. Moreover, such PWs that are used for interconnecting between a 301 remote AC and a VSI SHALL considered as separate logical VSI 302 interfaces with respect to MAC address learning/forwarding e.g. 303 traffic forwarding between such PWs is allowed as long as they are 304 not both defined as Leaf. 306 In Figure 3, AC1 is remotely interconnected to the VPLS service via 307 PW1, and AC2 is remotely interconnected to the VPLS service via PW2. 309 AC1 is a Root AC and therefore the local type for PW1 in PE1 SHALL 310 be Root. 312 AC2 is a Leaf AC and therefore the local type for PW2 in PE1 SHALL 313 be Leaf. 315 6. Backward Compatibility 317 Root or leaf VSI E-Tree type and identifier parameters SHALL be used 318 only in cases where both PEs are VPLS capable and both support E- 319 Tree root/leaf. 321 In a case where one of the peers do not support E-Tree, VSI E-Tree 322 type and identifier parameters SHALL NOT be used. 324 7. Compliance with Requirements 326 This refers to [Draft ETree VPLS Req] Section 5. Requirements. 328 The solution prohibits communication between any two Leaf ACs in a 329 VPLS instance. 331 The solution allows multiple Root ACs in a VPLS instance. 333 The solution allows Root AC and Leaf AC of a VPLS instance co-exist 334 on any PE. 336 The solution is applicable to LDP-VPLS [RFC4762]. 338 The solution is applicable to Case 1: Single technology "VPLS Only". 340 8. Security Considerations 342 This will be added in later version. 344 9. IANA Considerations 346 Additional assignments will be required for the new interface 347 parameter sub-TLV types introduced in Section 4.2. Details will be 348 added in a later version. 350 10. Acknowledgements 352 The authors wish to acknowledge the contributions of Luca Martini 353 and Amir Halperin. 355 11. References 357 11.1. Normative References 359 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 360 Requirement Levels, BCP 14, RFC 2119, March 1997. 362 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance 363 Using the Label Distribution Protocol (LDP), April 2006 365 [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) 366 Using Label Distribution Protocol (LDP) Signaling, January 2007 368 11.2. Informative References 370 [Draft VPLS ETree Req] Key, et al., Requirements for MEF E-Tree 371 Support in VPLS, draft-key-l2vpn-vpls-etree-reqt-01.txt, September 372 2010 374 Authors' Addresses 376 Rafi Ram 377 Orckit-Corrigent 378 126 Yigal Alon st. 379 Tel Aviv, Israel 380 Email: rafir@orckit.com 382 Daniel Cohn 383 Orckit-Corrigent 384 126 Yigal Alon st. 385 Tel Aviv, Israel 386 Email: danielc@orckit.com 388 Raymond Key 389 Telstra 390 242 Exhibition Street, Melbourne 391 VIC 3000, Australia 392 Email: raymond.key@team.telstra.com 394 Puneet Agarwal 395 Broadcom 396 3151 Zanker Road 397 San Jose, CA 95134 398 Email: pagarwal@broadcom.com