idnits 2.17.1 draft-allan-l2vpn-mldp-evpn-03.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 : ---------------------------------------------------------------------------- No issues found here. 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 (July 2014) is 3566 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) == Unused Reference: '2' is defined on line 275, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 278, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 281, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 298, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 303, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 306, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-01 -- No information found for draft-allan-l2vpn-spb-evpn - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-10) exists of draft-ietf-l2vpn-pbb-evpn-03 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L2VPN Working Group Dave Allan, Jeff Tantsura 2 Internet Draft Ericsson 3 Intended status: Standards Track Sam Aldrin 4 Expires: January 2015 Huawei 6 July 2014 8 mLDP extensions for integrating EVPN and multicast 9 draft-allan-l2vpn-mldp-evpn-03 11 Abstract 13 This document describes how mLDP FECs can be encoded to support both 14 service specific and shared multicast trees and describes the 15 associated procedures for EVPN PEs. Thus, mLDP can implement 16 multicast for EVPN. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance 21 with the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet 24 Engineering Task Force (IETF), its areas, and its working 25 groups. Note that other groups may also distribute working 26 documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as "work 32 in progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on July 2014. 42 Copyright and License Notice 44 Copyright (c) 2014 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. Code Components extracted from this 53 document must include Simplified BSD License text as described 54 in Section 4.e of the Trust Legal Provisions and are provided 55 without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction...................................................2 60 1.1. Authors......................................................2 61 1.2. Requirements Language........................................3 62 2. Changes since last version.....................................3 63 3. Conventions used in this document..............................3 64 3.1. Terminology..................................................3 65 4. Solution Overview..............................................4 66 5. Elements of Procedure..........................................4 67 6. FEC Encoding...................................................5 68 6.1. VLAN tagged FEC..............................................5 69 6.2. I-SID tagged FEC.............................................6 70 6.3. Shared FEC...................................................6 71 7. Acknowledgements...............................................7 72 8. Security Considerations........................................7 73 9. IANA Considerations............................................7 74 10. References....................................................7 75 10.1. Normative References........................................7 76 10.2. Informative References......................................8 77 11. Authors' Addresses............................................8 79 1. Introduction 81 This document describes how mLDP FECs can be encoded to permit mLDP 82 to implement multicast for EVPN. Such support can be applied to 83 interconnecting 802.1ad, 802.1ah, 802.1aq, and 802.1Qbp based 84 networks. 86 1.1. Authors 88 David Allan, Jeff Tantsura, Sam Aldrin 90 1.2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC2119 [1]. 96 2. Changes since last version 98 1) Added co-author. 100 3. Conventions used in this document 102 3.1. Terminology 104 BCB: Backbone Core Bridge 105 BEB: Backbone Edge Bridge 106 BU: Broadcast/Unknown 107 B-MAC: Backbone MAC Address 108 B-VID: Backbone VLAN ID 109 CE: Customer Edge 110 C-MAC: Customer/Client MAC Address 111 DF: Designated Forwarder 112 ESI: Ethernet segment identifier 113 EVPN: Ethernet VPN 114 FEC: Forwarding Equivalence Class 115 ISIS-SPB: IS-IS as extended for SPB 116 I-SID: Backbone Service Instance ID 117 mLDP: Multicast Label Distribution Protocol 118 MP2MP: Multipoint to Multipoint 119 MVPN: Multicast VPN 120 NLRI: Network layer reachability information 121 PBBN: Provider Backbone Bridged Network 122 BEB-PE: Co located BEB and PE 123 PE: provider edge 124 P2MP: Point to Multipoint 125 P2P: Point to Point 126 RD: Route Distinguisher 127 SPB: Shortest path bridging 128 SPBM: Shortest path bridging MAC mode 129 VID: VLAN ID 130 VLAN: Virtual LAN 132 4. Solution Overview 134 mLDP[6] permits arbitrary FEC encodings for the naming of multicast 135 trees to be defined. This property is leveraged to permit both 136 service specific trees and shared trees to be utilized to augment 137 EVPN unicast connectivity with network based multicast and avoid the 138 inefficiencies of edge replication. 139 The flooding of EVPN BGP NLRI and ISIS-SPB [7] provides each PE with 140 sufficient information to self elect as a DF, have knowledge of peer 141 DFs, and from that construct the identifiers for the required set of 142 multicast trees to support the current service set, which can then be 143 encoded as mLDP FECs, and used to originate label mapping and label 144 withdraw messages. 145 Both p2mp and mp2mp trees are supported with different FEC encodings 146 for each. Service specific tree FECs encode the VID or I-SID 147 associated with the service instance in the subtending network. 148 Shared tree FECs encode a sorted list of the IP addresses of the leaf 149 DFs. 151 5. Elements of Procedure 153 A PE advertises whether or not it supports shared tree (actual 154 mechanism is TBD). Support of both shared and service specific trees 155 is mandatory. Whether a PE supports shared trees is a network design 156 decision. 158 A PE is expected to maintain a list of current multicast memberships. 160 A PE, upon receipt of new information from BGP or ISIS-SPB: 162 1) Evaluates it"s DF roles (as described in [5]). 164 2) On the basis of the PE"s DF role, determines the set of services 165 it needs to support. 167 3) Determines the set of peer DFs for each service. 169 4) On the basis of requisite tree types and ESI multicast 170 registrations (p2mp or mp2mp/service specific or shared), determines 171 the name of the multicast tree needed for the service. 173 For example an ESI may only have source interest in an ISIS-SPB I-SID 174 in which case it would: 176 - require a p2mp tree to the set of DFs registering receive 177 interest in the I-SID for p2mp trees 179 - require an upstream label mapping to the set of DFs registering 180 receive interest in the I_SID for mp2mp trees 182 5) Upon completion of evaluating the set of services, de-duplicates 183 the required tree membership list. 185 6) Compares the required list with the existing list, and originates 186 the necessary label mapping and label withdraw transactions to the 187 network state up to date. 189 7) Configures the dataplane for the appropriate service to multicast 190 tree bindings. 192 6. FEC Encoding 194 6.1. VLAN tagged FEC 196 VLAN tagged FEC uses the mLDP p2mp (0x06) type FEC and the mLDP mp2mp 197 downstream (0x07) and upstream FECs (0x08) 199 The encoding of the opaque value is: 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type "x" | Length | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | RT | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Ethertype | VID | = 0 | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Where: 212 - RT is the route target for the EVPN instance 213 - Ethertype identifies the tag type (C 0x8100, S or B 0x88a8) 214 - VID is the VLAN ID tag value. If the VID=0, then this is the 215 default MDT for the RT and how VLAN unaware RTs are encoded, else it 216 permits MDTs to be defined for VLAN aware services. 218 6.2. I-SID tagged FEC 220 The encoding of the opaque value is: 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type "x+1" | Length | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | RT | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | I-SID | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Where: 232 - RT is the route target for the EVPN instance 233 - I-SID corresponds to the I-SID that will use the tree 235 6.3. Shared FEC 237 The encoding of the opaque value is: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type "x+2" | Length | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | RT | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 ~ ~ 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Where: 250 - RT is the route target for the EVPN instance 251 - Sorted list of DF addresses identifies the set of leaves that have 252 registered interest in one or more Ethernet services (either C/S or I 253 tagged). 255 7. Acknowledgements 257 The authors would like to thank Panagiotis Saltsidis, Jakob Heitz, 258 Don Fedyk and Janos Farkas for their detailed review of this draft. 260 8. Security Considerations 262 For a future version of this document. 264 9. IANA Considerations 266 For a future version of this document. 268 10. References 270 10.1. Normative References 272 [1] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 [2] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq 276 Shortest Path Bridging", IETF RFC 6329, April 2012 278 [3] Rosen et.al., "BGP/MPLS IP Virtual Private Networks 279 (VPNs)", IETF RFC 4364, February 2006 281 [4] Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF work 282 in progress, draft-ietf-l2vpn-evpn-01, July 2012 284 [5] Allan et.al. "802.1aq and 802.1Qbp Support over EVPN", 285 IETF work in progress, draft-allan-l2vpn-spb-evpn-03, 286 February 2013 288 [6] Wijnands et.al. "Label Distribution Protocol Extensions 289 for Point-to-Multipoint and Multipoint-to-Multipoint Label 290 Switched Paths". IETF RFC 6388, November 2011 292 10.2. Informative References 294 [7] IEEE 802.1aq "IEEE Standard for Local and Metropolitan 295 Area Networks: Bridges and Virtual Bridged Local Area 296 Networks - Amendment 9: Shortest Path Bridging", June 2012 298 [8] IEEE 802.1Qbp "Draft IEEE Standard for Local and 299 Metropolitan Area Networks---Virtual Bridged Local Area 300 Networks - Amendment: Equal Cost Multiple Paths (ECMP), 301 802.1Qbp", draft 1.3, February 2013 303 [9] Sajassi et.al. "PBB E-VPN", IETF work in progress, draft- 304 ietf-l2vpn-pbb-evpn-03, June 2012 306 [10] IEEE 802.1Q-2011 "IEEE Standard for Local and metropolitan 307 area networks--Media Access Control (MAC) Bridges and 308 Virtual Bridged Local Area Networks", August 2011 310 11. Authors' Addresses 312 Dave Allan (editor) 313 Ericsson 314 300 Holger Way 315 San Jose, CA 95134 316 USA 317 Email: david.i.allan@ericsson.com 319 Jeff Tantsura 320 Ericsson 321 300 Holger Way 322 San Jose, CA 95134 323 Email: jeff.tantsura@ericsson.com 325 Sam Aldrin 326 Huawei Technologies 327 2330 Central Expressway 328 Santa Clara, CA 95051 329 EMail: aldrin.ietf@gmail.com