idnits 2.17.00 (12 Aug 2021) /tmp/idnits50914/draft-ietf-bier-mldp-signaling-over-bier-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 : ---------------------------------------------------------------------------- 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 (12 November 2021) is 183 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 95, but not defined == Missing Reference: 'RFC6388' is mentioned on line 175, but not defined == Unused Reference: 'RFC8401' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC8444' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC8556' is defined on line 328, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Bidgoli, Ed. 3 Internet-Draft J. Kotalwar 4 Intended status: Informational Nokia 5 Expires: 16 May 2022 I. Wijnands 6 M. Mishra 7 Cisco System 8 Z. Zhang 9 Juniper Networks 10 E. Leyton 11 Verizon 12 12 November 2021 14 M-LDP Signaling Through BIER Core 15 draft-ietf-bier-mldp-signaling-over-bier-01 17 Abstract 19 Consider an end to end Multipoint LDP (mLDP) network, where it is 20 desirable to deploy BIER in portion of this network. It might be 21 desirable to deploy BIER with minimum disruption to the mLDP network 22 or redesign of the network. 24 This document describes the procedure needed for mLDP tunnels to be 25 signaled over and stitched through a BIER core, allowing LDP routers 26 to run traditional mLDP services through a BIER core. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 16 May 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions used in this document . . . . . . . . . . . . . . 2 63 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. mLDP Signaling Through BIER domain . . . . . . . . . . . . . 4 65 3.1. Ingress BBR procedure . . . . . . . . . . . . . . . . . . 5 66 3.1.1. Automatic tLDP session Creation . . . . . . . . . . . 5 67 3.1.2. ECMP Method on IBBR . . . . . . . . . . . . . . . . . 5 68 3.2. Egress BBR procedure . . . . . . . . . . . . . . . . . . 5 69 3.2.1. IBBR procedure for arriving upstream assigned 70 label . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Datapath traffic flow . . . . . . . . . . . . . . . . . . 6 73 5. Recursive FEC . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 7 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 9.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 Some operators that are using mLDP P2MP LSPs for their multicast 85 transport would like to deploy BIER technology in some segment of 86 their network. This draft explains a method to signal mLDP services 87 through a BIER domain, with minimal disruption and operational impact 88 to the mLDP domain. 90 2. Conventions used in this document 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 RFC 2119 [RFC2119]. 96 2.1. Definitions 98 Some of the terminology specified in [I-D.draft-ietf-bier- 99 architecture-05] is replicated here and extended by necessary 100 definitions: 102 BIER: 104 Bit Index Explicit Replication (The overall architecture of 105 forwarding multicast using a Bit Position). 107 BFR: 109 Bit Forwarding Router (A router that participates in Bit Index 110 Multipoint Forwarding). A BFR is identified by a unique BFR prefix 111 in a BIER domain. 113 BFIR: 115 Bit Forwarding Ingress Router (The ingress border router that inserts 116 the Bit Map into the packet). Each BFIR must have a valid BFR-id 117 assigned. BFIR is term used for dataplain packet forwarding. 119 BFER: 121 Bit Forwarding Egress Router. A router that participates in Bit 122 Index Forwarding as leaf. Each BFER must have a valid BFR-id 123 assigned. BFER is term used for dataplain packet forwarding. 125 BBR: 127 BIER Boundary router. The router between the LDP domain and BIER 128 domain. 130 IBBR: 132 Ingress BIER Boundary Router. The ingress router from signaling 133 point of view. It maintains mLDP adjacency toward the LDP domain and 134 determines if the mLDP FEC needs to be signaled across the BIER 135 domain via Targeted LDP. 137 EBBR: 139 Egress BIER Boundary Router. The egress router in BIER domain from 140 signaling point of view. It terminates the targeted ldp signaling 141 through BIER domain. It also keeps track of all IBBRs that are part 142 of this p2mp tree 143 BIFT: 145 Bit Index Forwarding Table. 147 BIER sub-domain: 149 A further distinction within a BIER domain identified by its unique 150 sub-domain identifier. A BIER sub-domain can support multiple 151 BitString Lengths. 153 BFR-id: 155 An optional, unique identifier for a BFR within a BIER sub- domain, 156 all BFERs and BFIRs need to be assigned a BFR-id. 158 3. mLDP Signaling Through BIER domain 160 bbr bbr 161 |---LDP Domain--|-----BIER domain-----|---LDP domain--| 162 S--( A )-----------( B ) ---- ( C ) ---- ( D )-----------( E )--h 164 ebbr ibbr 165 Sig <----MLDP------|<----targeted LDP----|<---MLDP------ 166 (new) 168 bfir bfer 169 ------------->|--------BIER-------->|-------------> Datapatah 170 (new) 172 Figure 1: BIER boundry router 174 As per figure 1, point-to-multipoint and multipoint-to-multipoint 175 LSPs established via mLDP [RFC6388] can be signaled through a bier 176 domain via Targeted LDP sessions. This procedure is explained in 177 [RFC7060] (Using LDP Multipoint Extension on Targeted LDP Sessions). 179 This documents provides details and defines some needed procedures. 181 . 183 3.1. Ingress BBR procedure 185 The Ingress BBR (IBBR) is connected to the mLDP domain on downstream 186 and a bier domain on the upstream. To connect the LDP domains via 187 BIER domain, IBBR needs to establish a targeted LDP session with EBBR 188 closest to the root of the P2MP or MP2MP LSP. To do so IBBR will 189 follow procedures in [RFC7060] in particular the section "6. targeted 190 mLDP with Multicast Tunneling". 192 The target LDP session can be established manually via configuration 193 or via automated mechanism. 195 3.1.1. Automatic tLDP session Creation 197 tLDP session can be signaled automatically from every IBBR to the 198 appropriate EBBR. When mLDP FEC arrives to IBBR from LDP domain, 199 IBBR can automatically start a tLDP Session to the EBBR closest to 200 the Root node. Both IBBR and EBBR should be in auto-discovery mode 201 and react to the arriving tLDP Signaling packets (i.e. targeted 202 hellos, keep- alives etc...) to establish the session automatically. 204 The Root node address in the mLDP FEC can be used to find the EBBR. 205 To identify the EBBR same procedures as [RFC7060] section 2.1 can be 206 used or the procedures as explained in the 207 [draft-ietf-bier-pim-signaling] appendix A. 209 3.1.2. ECMP Method on IBBR 211 If IBBR finds multiple equal cost EBBRs on the path to the Root, it 212 can use a vendor specific algorithm to choose between the EBBRs. 213 These algorithms are beyond the scope of this draft. As an example 214 the IBBR can use the smallest EBBR IP address to establish its mLDP 215 signaling to. 217 3.2. Egress BBR procedure 219 The Egress BBR (EBBR) is connected to the upstream mLDP domain. The 220 EBBR should accept the tLDP session generated form IBBR. It should 221 assign a unique "upstream assigned label" for each arriving FEC 222 generated by IBBRs. 224 The EBBR should follow the [RFC7060] procedures with following 225 modifications: 227 * The label assigned by EBBR cannot be Implicit Null. This is to 228 ensure that identity of each p2mp and/or mp2mp tunnel in BIER 229 domain is uniquely distinguished. 231 * The label can be assigned from a domain-wide Common Block (DCB) 232 [draft-zzhang-bess-mvpn-evpn-aggregation-label] 234 * The Interface ID TLV, as per [RFC6389] should includes a new BIER 235 sub-domain sub- tlv (type TBD) 237 The EBBR will also generate a new label and FEC toward the ROOT on 238 the LDP domain. The EBBR Should stitch this generate label with the 239 "upstream assigned label" to complete the P2MP or MP2MP LSP. 241 With same token the EBBR should track all the arriving FECs and the 242 IBBRs that are generating these FECs. EBBR will use this information 243 to build the bier header for each set of common FEC arriving from the 244 IBBRs. 246 3.2.1. IBBR procedure for arriving upstream assigned label 248 Upon receiving the "upstream assigned label", IBBR should create its 249 own stitching instruction between the "upstream assigned label" and 250 the down stream signaled label. 252 4. Datapath Forwarding 254 4.1. Datapath traffic flow 256 On BFIR when the MPLS label for P2MP/MP2MP LSP arrives from upstream, 257 a lookup in ILM table is done and the label is swapped with tLDP 258 upstream assigned label. The BFIR will note all the BFERs that are 259 interested in specific P2MP/MP2MP LSP (as per section 3.2). BFIR 260 will put the corresponding BIER header with bit index set for all 261 IBBRs interested in this stream. BFIR will set the BIERHeader.Proto 262 = MPLS and will forward the BIER packet into BIER domain. 264 In the BIER domain, normal BIER forwarding procedure will be done, as 265 per [RFC8279] 267 The BFERs will receive the BIER packet, will look at the protocol of 268 BIER header (MPLS). BFER will remove the BIER header and will do a 269 lookup in the ILM table for the upstream assigned label and perform 270 its corresponding action. 272 It should be noted that these procedures are also valid if BFIR is 273 the ILER and/or BFER is the ELER as per [RFC7060] 275 5. Recursive FEC 277 The above procedures also will work with a mLDP recursive FEC. The 278 root used to determine the EBBR is the outer root of the FEC. The 279 entire recursive FEC needs to be preserve when it is forwarded via 280 tLDP and the label request. 282 6. IANA Consideration 284 adf 286 1. A new BIER sub-domain sub- tlv for the interface ID TLV to be 287 assigned by IANA 289 7. Security Considerations 291 TBD 293 8. Acknowledgments 295 Acknowledgments Authors would like to acknowledge Jingrong Xie for 296 his comments and help on this draft. 298 9. References 300 9.1. Normative References 302 [draft-ietf-bier-pim-signaling] 303 "H, Bidgoli, F. Xu, J. Kotalwar, I. Wijnands, M. Mishra, 304 Z. Zhang", 29 July 2020. 306 [draft-zzhang-bess-mvpn-evpn-aggregation-label] 307 "Z. Zhang, E. Rosen, W. Lin, Z. Li, I. Wijnands, "MVPN/ 308 EVPN Tunnel Aggregation with Common Labels"", 27 April 309 2018. 311 [RFC6389] "R Aggarwal, JL. Le Roux, "MPLS Upstream Label Assignment 312 for LDP"", November 2011. 314 [RFC7060] "M. Napierala, E. Rosen, I. Wijnands", November 2013. 316 [RFC8279] "I. Wijnands, E. Rosen, A. ADolganow, T. Prygienda, S. 317 Aldrin", November 2017. 319 9.2. Informative References 321 [RFC8401] "Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 322 "BIER Support via ISIS"", June 2018. 324 [RFC8444] "Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 325 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 326 for Bit Index Explicit Replication"", June 2018. 328 [RFC8556] "Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, 329 S.,Dolganow, A., and T. Przygienda, "Multicast VPN Using 330 Index Explicit Replication (BIER)", April 2018. 332 Authors' Addresses 334 Hooman Bidgoli (editor) 335 Nokia 336 Ottawa 337 Canada 339 Email: hooman.bidgoli@nokia.com 341 Jayant Kotalwar 342 Nokia 343 Montain View, 344 United States of America 346 Email: jayant.kotalwar@nokia.com 348 IJsbrand Wijnands 349 Cisco System 350 Diegem 351 Belgium 353 Email: ice@cisco.com 355 Mankamana Mishra 356 Cisco System 357 Milpitas, 358 United States of America 360 Email: mankamis@cisco.com 362 Zhaohui Zhang 363 Juniper Networks 364 Boston, 365 United States of America 367 Email: zzhang@juniper.com 368 Eddie Leyton 369 Verizon 371 Email: Edward.leyton@verizonwireless.com