idnits 2.17.00 (12 Aug 2021) /tmp/idnits14593/draft-allan-l2vpn-mldp-evpn-00.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 (March 2013) is 3354 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 265, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 268, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 271, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 288, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 293, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 296, but no explicit reference was found in the text == Outdated reference: draft-ietf-l2vpn-evpn has been published as RFC 7432 -- No information found for draft-allan-l2vpn-spb-evpn - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: draft-ietf-l2vpn-pbb-evpn has been published as RFC 7623 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 4 Expires: August 2013 5 March 2013 7 mLDP extensions for integrating EVPN and multicast 8 draft-allan-l2vpn-mldp-evpn-00 10 Abstract 12 This document describes how mLDP FECs can be encoded to support both 13 service specific and shared multicast trees and describes the 14 associated procedures for EVPN PEs. Thus, mLDP can implement 15 multicast for EVPN. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance 20 with the provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as "work 31 in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 2013. 41 Copyright and License Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described 53 in Section 4.e of the Trust Legal Provisions and are provided 54 without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction..........................................2 59 1.1. Authors.............................................2 60 1.2. Requirements Language.................................2 61 2. Conventions used in this document........................3 62 2.1. Terminology.........................................3 63 3. Solution Overview......................................4 64 4. Elements of Procedure ..................................4 65 5. FEC Encoding..........................................5 66 6. Acknowledgements.......................................7 67 7. Security Considerations.................................7 68 8. IANA Considerations....................................7 69 9. References............................................7 70 9.1. Normative References..................................7 71 9.2. Informative References................................7 72 10. Authors' Addresses....................................8 74 1. Introduction 76 This document describes how mLDP FECs can be encoded to permit mLDP 77 to implement multicast for EVPN. Such support can be applied to 78 interconnecting 802.1ad, 802.1ah, 802.1aq, and 802.1Qbp based 79 networks. 81 1.1. Authors 83 David Allan, Jeff Tantsura 85 1.2. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC2119 [1]. 91 2. Conventions used in this document 93 2.1. Terminology 95 BCB: Backbone Core Bridge 96 BEB: Backbone Edge Bridge 97 BU: Broadcast/Unknown 98 B-MAC: Backbone MAC Address 99 B-VID: Backbone VLAN ID 100 CE: Customer Edge 101 C-MAC: Customer/Client MAC Address 102 DF: Designated Forwarder 103 ESI: Ethernet segment identifier 104 EVPN: Ethernet VPN 105 FEC: Forwarding Equivalence Class 106 ISIS-SPB: IS-IS as extended for SPB 107 I-SID: Backbone Service Instance ID 108 mLDP: Multicast Label Distribution Protocol 109 MP2MP: Multipoint to Multipoint 110 MVPN: Multicast VPN 111 NLRI: Network layer reachability information 112 PBBN: Provider Backbone Bridged Network 113 BEB-PE: Co located BEB and PE 114 PE: provider edge 115 P2MP: Point to Multipoint 116 P2P: Point to Point 117 RD: Route Distinguisher 118 SPB: Shortest path bridging 119 SPBM: Shortest path bridging MAC mode 120 VID: VLAN ID 121 VLAN: Virtual LAN 123 3. Solution Overview 125 mLDP[6] permits arbitrary FEC encodings for the naming of multicast 126 trees to be defined. This property is leveraged to permit both 127 service specific trees and shared trees to be utilized to augment 128 EVPN unicast connectivity with network based multicast and avoid the 129 inefficiencies of edge replication. 130 The flooding of EVPN BGP NLRI and ISIS-SPB [7] provides each PE with 131 sufficient information to self elect as a DF, have knowledge of peer 132 DFs, and from that construct the identifiers for the required set of 133 multicast trees to support the current service set, which can then be 134 encoded as mLDP FECs, and used to originate label mapping and label 135 withdraw messages. 136 Both p2mp and mp2mp trees are supported with different FEC encodings 137 for each. Service specific tree FECs encode the VID or I-SID 138 associated with the service instance in the subtending network. 139 Shared tree FECs encode a sorted list of the IP addresses of the leaf 140 DFs. 142 4. Elements of Procedure 144 A PE advertises whether or not it supports shared tree (actual 145 mechanism is TBD). Support of both shared and service specific trees 146 is mandatory. Whether a PE supports shared trees is a network design 147 decision. 149 A PE is expected to maintain a list of current multicast memberships. 151 A PE, upon receipt of new information from BGP or ISIS-SPB: 153 1) Evaluates it"s DF roles (as described in . 154 [5]). 156 2) On the basis of the PE"s DF role, determines the set of services 157 it needs to support. 159 3) Determines the set of peer DFs for each service. 161 4) On the basis of requisite tree types and ESI multicast 162 registrations (p2mp or mp2mp/service specific or shared), determines 163 the name of the multicast tree needed for the service. 165 For example an ESI may only have source interest in an ISIS-SPB I-SID 166 in which case it would: 168 - require a p2mp tree to the set of DFs registering receive 169 interest in the I-SID for p2mp trees 171 - require an upstream label mapping to the set of DFs registering 172 receive interest in the I_SID for mp2mp trees 174 5) Upon completion of evaluating the set of services, de-duplicates 175 the required tree membership list. 177 6) Compares the required list with the existing list, and originates 178 the necessary label mapping and label withdraw transactions to the 179 network state up to date. 181 7) Configures the dataplane for the appropriate service to multicast 182 tree bindings. 184 5. FEC Encoding 186 5.1. VLAN tagged FEC 188 VLAN tagged FEC uses the mLDP p2mp (0x06) type FEC and the mLDP mp2mp 189 downstream (0x07) and upstream FECs (0x08) 191 The encoding of the opaque value is: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Type "x" | Length | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | RT | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Ethertype | VID | = 0 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Where: 203 - RT is the route target for the EVPN instance 204 - Ethertype identifies the tag type (C 0x8100, S or B 0x88a8) 205 - VID is the VLAN ID tag value 207 5.2. I-SID tagged FEC 209 The encoding of the opaque value is: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type "x+1" | Length | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | RT | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | I-SID | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Where: 221 - RT is the route target for the EVPN instance 222 - I-SID corresponds to the I-SID that will use the tree 224 5.3. Shared FEC 226 The encoding of the opaque value is: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type "x+2" | Length | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | RT | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 ~ ~ 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Where: 240 - RT is the route target for the EVPN instance 241 - Sorted list of DF addresses identifies the set of leaves that have 242 registered interest in one or more Ethernet services (either C/S or I 243 tagged). 245 6. Acknowledgements 247 The authors would like to thank Panagiotis Saltsidis and Janos Farkas 248 for their detailed review of this draft. 250 7. Security Considerations 252 For a future version of this document. 254 8. IANA Considerations 256 For a future version of this document. 258 9. References 260 9.1. Normative References 262 [1] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [2] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq 266 Shortest Path Bridging", IETF RFC 6329, April 2012 268 [3] Rosen et.al., "BGP/MPLS IP Virtual Private Networks 269 (VPNs)", IETF RFC 4364, February 2006 271 [4] Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF work 272 in progress, draft-ietf-l2vpn-evpn-01, July 2012 274 [5] Allan et.al. "802.1aq and 802.1Qbp Support over EVPN", 275 IETF work in progress, draft-allan-l2vpn-spb-evpn-03, 276 February 2013 278 [6] Wijnands et.al. "Label Distribution Protocol Extensions 279 for Point-to-Multipoint and Multipoint-to-Multipoint Label 280 Switched Paths". IETF RFC 6388, November 2011 282 9.2. Informative References 284 [7] IEEE 802.1aq "IEEE Standard for Local and Metropolitan 285 Area Networks: Bridges and Virtual Bridged Local Area 286 Networks - Amendment 9: Shortest Path Bridging", June 2012 288 [8] IEEE 802.1Qbp "Draft IEEE Standard for Local and 289 Metropolitan Area Networks---Virtual Bridged Local Area 290 Networks - Amendment: Equal Cost Multiple Paths (ECMP), 291 802.1Qbp", draft 1.3, February 2013 293 [9] Sajassi et.al. "PBB E-VPN", IETF work in progress, draft- 294 ietf-l2vpn-pbb-evpn-03, June 2012 296 [10] IEEE 802.1Q-2011 "IEEE Standard for Local and metropolitan 297 area networks--Media Access Control (MAC) Bridges and 298 Virtual Bridged Local Area Networks", August 2011 300 10. Authors' Addresses 302 Dave Allan (editor) 303 Ericsson 304 300 Holger Way 305 San Jose, CA 95134 306 USA 307 Email: david.i.allan@ericsson.com 309 Jeff Tantsura 310 Ericsson 311 300 Holger Way 312 San Jose, CA 95134 313 Email: jeff.tantsura@ericsson.com