idnits 2.17.1 draft-chen-l2vpn-vpls-etree-vlan-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([I-D.ietf-l2vpn-etree-reqt]), 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 21, 2012) is 4412 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: 'RFC 4761' is mentioned on line 171, but not defined == Unused Reference: 'RFC2119' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 257, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-05) exists of draft-ietf-l2vpn-etree-reqt-00 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group R. Chen 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track March 21, 2012 5 Expires: September 22, 2012 7 Automatic VLAN allocation in E-tree 8 draft-chen-l2vpn-vpls-etree-vlan-01 10 Abstract 12 This document proposes to use automatically allocated VLAN ID to 13 indicate E-Tree attribute. For the E-Tree requirement, please refer 14 to [I-D.ietf-l2vpn-etree-reqt] for detail. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 22, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions used in this document . . . . . . . . . . . . . . . 3 52 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Allocation mechanism . . . . . . . . . . . . . . . . . . . . . 4 54 5. Extension to LDP-VPLS for E-tree support . . . . . . . . . . . 5 55 6. Extension to BGP-VPLS for E-tree support . . . . . . . . . . . 6 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 8.1. Normative references . . . . . . . . . . . . . . . . . . . 7 59 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 1. Introduction 64 This document proposes to use automatically allocated VLAN ID to 65 indicate E-Tree attribute. For the E-Tree requirement, please refer 66 to [I-D.ietf-l2vpn-etree-reqt] for detail. 68 In order to achieve better compatibility and traffic optimization, 69 this document also introduces extensions to existing VPLS protocols 70 as described in the document. 72 2. Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC2119. 78 3. Approach 80 In order to be compatible with IEEE defined E-Tree, the approach in 81 this draft uses the VLAN ID to indicate Root/Leaf attribute of the 82 frame. 84 There are two ways to manipulate VLANs for an E-Tree in VPLS: 85 o Static configuring VLAN in IEEE, the Root/Leaf VLAN should co- 86 ordinate manually or by management plane to be configured same on 87 all the PEs in VPLS; 88 o Unlike static configuring VLAN in IEEE, VPLS PE has the capability 89 to create VLAN ID automatically, e.g. The VLAN ID can be derived 90 from the PW type/AGI automatically via some algorithm; 92 Regarding some VPLS PEs have single VLAN space without VLAN 93 translation, and only support VLAN mapping to VPLS instance, and then 94 if these PEs want to support VPLS E-tree, static configuring VLAN in 95 IEEE would be used. 97 Regarding some VPLS PEs support multiple VLAN spaces, then if these 98 PEs want to support VPLS E-tree, an optimized approach would be used, 99 which is automatic allocated VLAN. Unlike static configuring VLAN ID 100 in IEEE, VPLS PE has the capability to create VLAN ID automatically, 101 e.g. The VLAN ID can be derived from the PW type/AGI automatically 102 via some algorithm. As part of VLAN auto-derive procedure, operators 103 only need to configure the AC Leaf/Root properties, and not necessary 104 to care about the exact VLAN number. One VLAN ID(Root VLAN ID) is 105 used to indicate the frame originated from the Root AC and the other 106 VLAN ID(Leaf VLAN ID) is used to indicate the frame originated from 107 the Leaf AC between the pair of the PEs. 109 <-----------------E-Tree-----------> 110 +---------+ +---------+ 111 | PE1 | | PE2 | 112 +---+ | +----+ | | +----+ | +---+ 113 |CE1|---AC1----|--| | | | | |-|----AC3---|CE3| 114 +---+(Root AC) | | V | | Ethernet | | V | |(Root AC) +---+ 115 | | S |-|------PW------| | S | | 116 +---+ | | I | | | | I | | +---+ 117 |CE2|---AC2----|--| | | | | |-|----AC4---|CE4| 118 +---+(Leaf AC) | +----+ | | +----+ |(Leaf AC) +---+ 119 +---------+ +---------+ 121 Figure 1 123 As shown in figure 1, the VPLS PE1 and PE2 can both be attached with 124 root/leaf AC, the VLANs which is used to indicate the Root/leaf can 125 be derived from the PW type/AGI automatically. 127 When PE1 receives a frame via the Root AC, PE1 can add the Root VLAN 128 ID. When PE2 receives the frame from PE1 via the Ethernet PW, PE2 129 knows the frame originated from the Root, so it can forward the frame 130 to AC3(Root AC) and AC4 (Leaf AC). 132 When PE1 receives a frame via the Leaf AC, PE1 can add the leaf VLAN 133 ID. When PE2 receives the frame from PE1 via the Ethernet PW, PE2 134 knows the frame originated from the Leaf, so it can forward the frame 135 to AC3 (Root AC) but it must not be forwarded to any Leaf AC. 137 The approach allows the egress PE to make a decision whether the 138 frame can be forwarded or dropped towards a leaf AC. But in some 139 special scenarios, e.g. one of the VPLS PE is attached with only 140 leaves, some optimization should be done on the ingress PE to make a 141 decision whether this frame should be forwarded or dropped. Such 142 kind of mechanism can improve the bandwidth efficiency. The 143 extension to VPLS for the PE attached with leaves only is defined in 144 section 5. 146 4. Allocation mechanism 148 As part of VLAN auto-derive procedure, each PE can only need to 149 configure the Leaf/Root properties for each AC. Both the PWid FEC 150 element and the Generalized PWid FEC Element can be used to set up 151 the VPLS as defined in [RFC4762]. "MOD" operation is used to get 152 Leaf/Root VLAN ID. In some chips, one VLAN space will not support 153 all VLANs from 0~4094, then in order to make automatic allocated 154 Root/Leaf VLANs be within the VLAN space, so we define this 155 opertation. 156 o Root ID = (ID) MOD (Maximum VLAN -Minimum VLAN)+Minimum VLAN + 1 + 157 offset ; 158 o Leaf ID = (ID) MOD (Maximum VLAN -Minimum VLAN)+Minimum VLAN + 2 + 159 offset 161 For the PWid FEC element, PW type could be used as the ID, then every 162 PE in all VPLS instances obtains one pair of VLANs indicate Root 163 VLAN, Leaf VLAN respectively. 165 For the Generalized PWid FEC, AGI/PW type is used as ID, and AGI is 166 defined in [RFC5003]. AGI as a VPLS ID would be the same at a 167 particular VPLS instance, and every PE uses the same "mod" operation 168 to obtain Leaf/Root VLAN from the VPLS ID. So every PE in the same 169 VPLS instance obtains the same Root/Leaf VLAN. 171 For the BGP-VPLS [RFC 4761], Import-RT+Export-RT could be used as ID. 172 Import-RT+Export-RT would be same at a particular VPLS instance, and 173 every PE uses the same "mod" operation to obtain Leaf/Root VLAN from 174 the VPLS ID. So every PE in the same VPLS instance obtains the same 175 Root/Leaf VLAN. 177 5. Extension to LDP-VPLS for E-tree support 179 In addition to the signaling procedures for setting up PW as 180 specified in RFC4447, one new PW interface parameter sub-TLV,the 181 E-tree sub-TLV, is defined to use in E-Tree VPLS. 183 The E-tree sub-TLV is defined as follows: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | E-tree (IANA) | Length | Reserved |P| 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | offset | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 2 195 In the above figure, reserved bit must be set to 0 when transmitting, 196 and must be ignored upon receive. P bit is used to flag the PE which 197 is attached with only leaves as follows: 199 o P=1: the PE is attached with only leaves; 200 o P=0: the PE is attached with roots and leaves or is attached with 201 only roots. 203 For offset, it should be 16-bit. It is configurable, if the operator 204 uses different offset, it will lead some confusion. 206 This TLV must be carried in label mapping message. If a PE supports 207 E-tree service, it must send this E-tree sub-TLV and include its 208 local offset value. A PE is attached with only leaves should set the 209 P bit to 1. 211 When a PE2 that received such a Label mapping message from its peer 212 PE1, it knows that the PE1 has the E-tree capability. PE2 should 213 check if the local configure match the offset value that carried in 214 the Label mapping message, and if PE1 is attached with only leaves. 216 6. Extension to BGP-VPLS for E-tree support 218 In addition to the signaling procedures for setting up PW as 219 specified in [RFC4761], only a new extended community is defined to 220 use in E-Tree VPLS. 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Extended community type | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | offset | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Reserved |P| 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 3 232 For offset, it should be 16-bit. It is configurable, if the operator 233 uses different offset, it will lead some confusion. 235 P is a Leaf-only bit, it is set to 1 to indicate that the PE is 236 attached with only leaves, and set to 0 otherwise. 238 In figure 1, when a PE2 receives BGP UPDATE message with an E-Tree 239 Extended Community from its peer PE1, it knows that the PE1 has the 240 E-tree capability.PE2 should check if the local configure match the 241 TPID value that carried in the E-Tree Extended Community, and if PE1 242 is attached with only leaves. 244 7. IANA Considerations 246 This document creates a new interface parameter sub-TLV types (E-tree 247 sub-TLV) that is allocated by IANA, and a value of 0X18 is suggested 248 for assignment with this sub-TLV. 250 8. References 252 8.1. Normative references 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 258 Heron, "Pseudowire Setup and Maintenance Using the Label 259 Distribution Protocol (LDP)", RFC 4447, April 2006. 261 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 262 (VPLS) Using BGP for Auto-Discovery and Signaling", 263 RFC 4761, January 2007. 265 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 266 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 267 RFC 4762, January 2007. 269 [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, 270 "Attachment Individual Identifier (AII) Types for 271 Aggregation", RFC 5003, September 2007. 273 8.2. Informative References 275 [I-D.ietf-l2vpn-etree-reqt] 276 Key, R., Huang, L., Liu, Z., Paul, M., Kunze, R., Regno, 277 N., and J. Rogers, "Requirements for MEF E-Tree Support in 278 VPLS", draft-ietf-l2vpn-etree-reqt-00 (work in progress), 279 October 2011. 281 Author's Address 283 Ran Chen 284 ZTE Corporation 285 NO.19 East Huayuan Road 286 Haidian District Beijing 100191 287 P.R.China 289 Email: chen.ran@zte.com.cn