idnits 2.17.1 draft-zzhang-mvpn-evpn-controller-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 date (November 4, 2019) is 1633 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: 'RFC4360' is mentioned on line 279, but not defined -- Looks like a reference, but probably isn't: '6514' on line 279 -- Looks like a reference, but probably isn't: '7432' on line 279 == Unused Reference: 'I-D.ietf-bess-evpn-bum-procedure-updates' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-mvpn-evpn-aggregation-label' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'I-D.parekh-bess-mvpn-sr-p2mp' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'I-D.voyer-pim-sr-p2mp-policy' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'I-D.zzhang-bess-bgp-multicast-controller' is defined on line 333, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-07 == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-03 == Outdated reference: A later version (-01) exists of draft-parekh-bess-mvpn-sr-p2mp-00 == Outdated reference: A later version (-02) exists of draft-voyer-pim-sr-p2mp-policy-00 == Outdated reference: A later version (-02) exists of draft-zzhang-bess-bgp-multicast-controller-01 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 bess Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Parekh 5 Expires: May 7, 2020 Cisco Systems 6 Z. Zhang 7 ZTE 8 Bidgoli 9 Nokia 10 November 4, 2019 12 MVPN and EVPN BUM Signaling with Controllers 13 draft-zzhang-mvpn-evpn-controller-00 15 Abstract 17 This document specifies optional procedures for BGP-MVPN and EVPN BUM 18 signaling with controllers. When P2MP tunnels used for BGP-MVPN and 19 EVPN BUM are to be signaled from controllers, the controllers can 20 learn tunnel information (identifier, root, leaf) by participating 21 BGP-MVPN and EVPN BUM signaling, instead of relying on ingress PEs to 22 collect the information and then pass to the controllers. 23 Additionally, Inclusive/Selective PMSI Auto Discovery Routes can be 24 originated from controllers based on central provisioning, instead of 25 from PEs based on local provisioning. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14 [RFC2119] [RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 7, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Controller Address Extended Community . . . . . . . . . . 4 72 3.2. Targeting Leaf A-D Routes to Controllers . . . . . . . . 4 73 3.3. Controller Originated I/S-PMSI Routes . . . . . . . . . . 5 74 3.3.1. Inter-AS/Region Segmentation . . . . . . . . . . . . 5 75 3.4. Automatic DCB Label Allocation by Controllers . . . . . . 6 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 81 7.2. Informative References . . . . . . . . . . . . . . . . . 7 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 84 1. Terminologies 86 Familiarity with MVPN/EVPN protocols and procedures is assumed. Some 87 terminologies are listed below for convenience. 89 o PMSI: P-Multicast Service Interface - a conceptual interface for a 90 PE to send customer multicast traffic to all or some PEs in the 91 same VPN/BD. 93 o I-PMSI: Inclusive PMSI - to all PEs in the same VPN/BD. 95 o S-PMSI: Selective PMSI - to some of the PEs in the same VPN/BD. 97 o Leaf A-D routes: For explicit leaf tracking purpose. Triggered by 98 S-PMSI A-D routes and targeted at triggering route's originator. 100 o IMET A-D route: Inclusive Multicast Ethernet Tag A-D route. The 101 EVPN equivalent of MVPN Intra-AS I-PMSI A-D route. 103 As pointed out above, the EVPN IMET route is the equivalent of MVPN 104 I-PMSI A-D route. In the rest of the document, unless explicitly 105 stated, I-PMSI A-D route refers to MVPN Intra-AS I-PMSI A-D route 106 and/or EVPN IMET route. 108 2. Introduction 110 Consider a provider network with BGP-MVPN/EVPN where controllers are 111 used to set up P2MP tunnels per [draft-zzhang-bess-bgp-multicast- 112 controller] or [draft-voyer-pim-sr-p2mp-policy]. For a controller to 113 calculate the corresponding trees and set up the tunnels, it needs to 114 learn the (ID, root, leaf) information for those trees. Currently, 115 [draft-parekh-bess-mvpn-sr-p2mp] specifies that an ingress PE assigns 116 the SR P2MP ID and collects leaf information via Leaf A-D routes, and 117 then pass onto the controller. Observing that BGP-MVPN/EVPN 118 signaling typically involves Router Reflectors, which may typically 119 be hosted on or co-located with controllers, it makes sense to have 120 the controllers participating BGP-MVPN/EVPN signaling to learn (ID, 121 root, leaf) information. This will relieve the PEs from maintaining 122 Leaf A-D routes, and remove the extra hop of leaf information 123 propagation. 125 Also Consider that in the same network many selective tunnels are 126 used, and their usages are dynamically provisioned based on specific 127 needs at different time. For example, the provider provides video 128 transmission services for events at various time, location and to 129 various receivers. With traditional methods the provider would 130 provision the PEs at the transmission sources with various selective 131 tunnels, which triggers corresponding S-PMSI A-D routes. The 132 provisioning is put in place shortly before an event takes place and 133 removed shortly after the event ends. Alternatively and preferrably, 134 a controller can originate S-PMSI A-D routes based on centralized 135 provisioning on behalf of the source PEs. The controller also 136 collects the leaf information (either based on centralized 137 provisioning or based on Leaf A-D routes), calculates the tree and 138 signal tree nodes. Additionally, when tunnel aggregation labels are 139 allocated from Domain-wide Common Block (DCB), originating I/S-PMSI 140 A-D routes from controllers makes the DCB label allocation a lot 141 easier. 143 It is possible that an operator prefers automatic DCB aggregation 144 label allocation by the controller but prefers I/S-PMSI A-D routes 145 origination from individual PEs. In that case, a PE can target an I/ 146 S-PMSI A-D route at the controller and the controller will allocate a 147 DCB label and return it in a corresponding Leaf A-D route. 149 3. Specification 151 The procedures specified in this section applies if one or more 152 controllers participate MVPN/EVPN signaling for the purpose of leaf 153 discovery for P2MP tree calculation, and/or if controllers are to 154 originate I/S-PMSI A-D routes or BGP-MVPN and/or BGP-EVPN BUM. 156 3.1. Controller Address Extended Community 158 This document defines a new Transitive IPv4-Address-Specific Extended 159 Community Sub-Type: "Controller Address". This document also defines 160 a new BGP Transitive IPv6-Address-Specific Extended Community Sub- 161 Type: "Controller Address". 163 A Controller Address Extended Community (referred to as Controller 164 EC) is constructed by setting the Global Administrator field to the 165 IP address of the controller and the Local Administrator field to 0. 167 3.2. Targeting Leaf A-D Routes to Controllers 169 When a PE originates an I/S-PMSI A-D route with PTA's tunnel type set 170 to PIM-SSM/ASM, mLDP or SR P2MP that are to be set up by controllers, 171 the PE MUST attach a Controller EC constructed as above. If there 172 are multiple controllers, then one Controller EC is attached for each 173 of the controllers. 175 In case of tunnel segmentation and a new controller is used for the 176 next segmentation region, when an ABR/ASBR/RBR re-advertises the I/ 177 S-PMSI A-D route to the next segmentation region it MUST modify the 178 Controller EC to specify the new controller address. 180 When a PE/ABR/ASBR/RBR receives an I/S-PMSI A-D route with the 181 Controller EC, it MUST originate a corresponding Leaf A-D route. The 182 PTA from the I/S-PMSI A-D route is copied to the Leaf A-D route, and 183 an IP Address Specific Route Target to attached to the Leaf A-D 184 route. The Global Administrator field of the RT is set to the 185 address of the controller (as encoded in the received Controller EC), 186 and the Local Administrator field is set to 0. 188 Note that, the above is done even if the Leaf Information Required 189 (LIR) bit in the Flags field of the I/S-PMSI A-D route's PMSI Tunnel 190 Attribute (PTA) is not set. If the LIR bit in the Flags field of the 191 I/S-PMSI A-D route's PTA is set, then the above mentioned RTs are in 192 addition to the RT that the PE attaches according to the procedures 193 in [RFC6514], [RFC7524], or [draft-zzhang-bess-evpn-bum-procedure- 194 updates]. In other words, the Leaf A-D route will have RTs for both 195 the controllers and the upstream PE or segmentation points. 197 When a controller receives the advertisement and/or withdrawl of Leaf 198 A-D routes, it derives the set of leaves for the tunnel identified in 199 the PTA, calculate and set up the tree according to procedurs in 200 [draft-zzhang-bess-bgp-multicast-controller] or [draft-voyer-pim-sr- 201 p2mp-policy]. The controller does not further propagate the received 202 advertisement and/or withdrawl, unless there are other RTs attached. 204 3.3. Controller Originated I/S-PMSI Routes 206 When I/S-PMSI A-D routes are to be originated from the controllers, 207 it is expected that the controller, based on central planning, has 208 the knowledge of each VPN/BD's Route Target, each PE's RD for the 209 VPN/BD, and the Tunnel Type and Identifier for each I/S-PMSI. If the 210 tunnel aggregation is used, the controllers also allocate labels from 211 the DCB for the I/S-PMSIs. 213 The controller constructs the I/S-PMSI A-D route the same way as if 214 an ingress PE would be originating the routes. There are some 215 exceptions in case inter-AS/region segmentation is used, as specified 216 in Section 3.3.1. 218 Specifically, the controller uses the ingress PE's RD and RTs for the 219 VPN/BD, and use the ingress PE's address as "Originating Router's IP 220 Address" when constructing the I/S-PMSI A-D routes. The routes are 221 sent with the controller's address as next-hop initially, though the 222 next-hop may change as the routes propagates. 224 When the Ingress PE router receives the I/S-PMSI A-D routes, it sets 225 up corresponding forwarding state as if it originated the routes per 226 its local provisioning. Note that the next-hop address of the routes 227 will be different from the case where the ingress PE originates the 228 routes, but this should not matter. 230 3.3.1. Inter-AS/Region Segmentation 232 In case of segmentation, instead of using the Route Target for the 233 VPN/BD, the controller constructs an IP Address specific Route Target 234 with the Global Administrator Field set to the corresponding ingress 235 PE's address and the Local Administrator Field set to 0. This 236 targets the I/S-PMSI A-D routes to the Ingress PEs only. 238 The controller also sets the Originating Router's IP Address field of 239 the I/S-PMSI A-D route to its own address. 241 The receiving Ingress PE associate the I/S-PMSI A-D route to the 242 corresponding VRF/BD based on the RD of the received route. It then 243 re-originate a corresponding I/S-PMSI A-D route based on the received 244 I/S-PMSI A-D route from the controller by doing the following: 246 o Changing the Originating Router's IP address to its own 248 o Replacing the Route Target with the Route Target for the VPN/BD 250 3.4. Automatic DCB Label Allocation by Controllers 252 If it is desired for a PE to originate I/S-PMSI A-D routes on its own 253 but with DCB labels dynamically allcated by a controller, the PE 254 originates the I/S-PMSI A-D route with the Tunnel Type in the PTA set 255 to "no tunnel information present", the LIR bit in the PTA'S Flags 256 field set to 1, and attaches an IP Address Specific RT. The RT's 257 Global Administrator Field is set to the Controller's address and 258 Local Administrator field is set to 0. 260 When the controller receives the I/S-PMSI A-D route, it allocates a 261 DCB label and responds with a Leaf A-D route. The Label field of the 262 Leaf A-D route's PTA is set to the allocated DCB label. 264 When the PE receives the Leaf A-D route, it re-advertises the I/ 265 S-PMSI A-D route, with an additional RT for the corresponding VPN/BD. 266 The PTA's tunnel information is set as needed and the Label field is 267 set to the DCB label received in the Leaf A-D route. The LIR bit in 268 the Flags field of the PTA is set to 1 or 0 as needed. If it is set 269 to 0, the controller withdraws the Leaf A-D route but does not 270 release the allocated label. 272 When the PE withdraws the I/S-PMSI A-D route, the controller release 273 the DCB label and withdraws the corresponding Leaf A-D route if it 274 had not been withdrawn before. 276 4. Security Considerations 278 This document does not change security aspects as discussed in 279 [RFC4360], [6514], [7432], and [ietf-bess-evpn-bum-procedure- 280 updates]. 282 5. IANA Considerations 284 To be added. 286 6. Acknowledgements 288 7. References 290 7.1. Normative References 292 [I-D.ietf-bess-evpn-bum-procedure-updates] 293 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 294 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 295 bess-evpn-bum-procedure-updates-07 (work in progress), 296 August 2019. 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, 300 DOI 10.17487/RFC2119, March 1997, 301 . 303 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 304 Encodings and Procedures for Multicast in MPLS/BGP IP 305 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 306 . 308 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 309 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 310 May 2017, . 312 7.2. Informative References 314 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 315 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 316 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 317 ietf-bess-mvpn-evpn-aggregation-label-03 (work in 318 progress), October 2019. 320 [I-D.parekh-bess-mvpn-sr-p2mp] 321 Parekh, R., Filsfils, C., Venkateswaran, A., Bidgoli, H., 322 daniel.voyer@bell.ca, d., and C. Hassen, "Multicast VPN 323 with Segment Routing Point-to-Multipoint Segment", draft- 324 parekh-bess-mvpn-sr-p2mp-00 (work in progress), March 325 2019. 327 [I-D.voyer-pim-sr-p2mp-policy] 328 daniel.voyer@bell.ca, d., Filsfils, C., Parekh, R., 329 Bidgoli, H., and Z. Zhang, "Segment Routing Point-to- 330 Multipoint Policy", draft-voyer-pim-sr-p2mp-policy-00 331 (work in progress), October 2019. 333 [I-D.zzhang-bess-bgp-multicast-controller] 334 Zhang, Z., Raszuk, R., Pacella, D., and A. Gulko, 335 "Controller Based BGP Multicast Signaling", draft-zzhang- 336 bess-bgp-multicast-controller-01 (work in progress), 337 February 2019. 339 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 340 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 341 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 342 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 343 . 345 Authors' Addresses 347 Zhaohui Zhang 348 Juniper Networks 350 EMail: zzhang@juniper.net 352 Rishabh Parekh 353 Cisco Systems 355 EMail: riparekh@cisco.com 357 Zheng Zhang 358 ZTE 360 EMail: zhang.zheng@zte.com.cn 362 Hooman Bidgoli 363 Nokia 365 EMail: hooman.bidgoli@nokia.com