idnits 2.17.1 draft-ietf-bier-mldp-signaling-over-bier-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 (November 01, 2020) is 1272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 93, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 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: May 5, 2021 I. Wijnands 6 M. Mishra 7 Cisco System 8 Z. Zhang 9 Juniper Networks 10 E. Leyton 11 Verizon 12 November 01, 2020 14 M-LDP Signaling Through BIER Core 15 draft-ietf-bier-mldp-signaling-over-bier-00 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 May 5, 2021. 45 Copyright Notice 47 Copyright (c) 2020 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 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions used in this document . . . . . . . . . . . . . . 2 64 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. mLDP Signaling Through BIER domain . . . . . . . . . . . . . 4 66 3.1. Ingress BBR procedure . . . . . . . . . . . . . . . . . . 4 67 3.1.1. Automatic tLDP session Creation . . . . . . . . . . . 5 68 3.1.2. ECMP Method on IBBR . . . . . . . . . . . . . . . . . 5 69 3.2. Egress BBR procedure . . . . . . . . . . . . . . . . . . 5 70 3.2.1. IBBR procedure for arriving upstream assigned label . 6 71 4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Datapath traffic flow . . . . . . . . . . . . . . . . . . 6 73 5. Recursive FEC . . . . . . . . . . . . . . . . . . . . . . . . 6 74 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 7 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 77 9. Informative References . . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 Some operators that are using mLDP P2MP LSPs for their multicast 83 transport would like to deploy BIER technology in some segment of 84 their network. This draft explains a method to signal mLDP services 85 through a BIER domain, with minimal disruption and operational impact 86 to the mLDP domain. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 2.1. Definitions 96 Some of the terminology specified in [RFC8279] is replicated here and 97 extended by necessary definitions: 99 BIER: 101 Bit Index Explicit Replication (The overall architecture of 102 forwarding multicast using a Bit Position). 104 BFR: 106 Bit Forwarding Router (A router that participates in Bit Index 107 Multipoint Forwarding). A BFR is identified by a unique BFR Prefix 108 in a BIER domain. 110 BFIR: 112 Bit Forwarding Ingress Router (The ingress border router that inserts 113 the Bit Map into the packet). Each BFIR must have a valid BFR-id 114 assigned. BFIR is term used for dataplain packet forwarding. 116 BFER: 118 Bit Forwarding Egress Router. A router that participates in Bit 119 Index Forwarding as leaf. Each BFER must be a BFR. Each BFER must 120 have a valid BFR-id assigned. BFER is term used for dataplain packet 121 forwarding. 123 BBR: 125 BIER Boundary router. The router between the LDP domain and BIER 126 domain. 128 IBBR: 130 Ingress BIER Boundary Router. The ingress router from signaling 131 point of view. It maintains mLDP adjacency toward the LDP domain and 132 determines if the mLDP FEC needs to be signaled across the BIER 133 domain via Targeted LDP. 135 EBBR: 137 Egress BIER Boundary Router. The egress router in BIER domain from 138 signaling point of view. It terminates the targeted ldp signaling 139 through BIER domain. It also keeps track of all IBBRs that are part 140 of this P2MP tree 141 BIFT: 143 Bit Index Forwarding Table. 145 BIER sub-domain: 147 A further distinction within a BIER domain identified by its unique 148 sub-domain identifier. A BIER sub-domain can support multiple 149 BitString Lengths. 151 BFR-ID. 153 An optional, unique identifier for a BFR within a BIER sub-domain. 154 All BFERs and BFIRs need to be assigned a BFR-ID. 156 3. mLDP Signaling Through BIER domain 158 bbr bbr 159 |---LDP Domain--|-----BIER domain-----|---LDP domain--| 160 S--( A )-----------( B ) ---- ( C ) ---- ( D )-----------( E )--h 162 ebbr ibbr 163 Sig <----MLDP------|<----targeted LDP----|<---MLDP------ 164 (new) 166 bfir bfer 167 ------------->|--------BIER-------->|-------------> Datapatah 168 (new) 170 Figure 1: BIER boundry router 172 As per figure 1, point-to-multipoint (P2MP) and multipoint-to- 173 multipoint (MP2MP) LSPs established via mLDP [RFC6388] can be 174 signaled through a bier domain via Targeted LDP sessions. This 175 procedure is explained in [RFC7060] (Using LDP Multipoint Extension 176 on Targeted LDP Sessions). 178 This documents provides details and defines some needed procedures. 180 . 182 3.1. Ingress BBR procedure 184 The Ingress BBR (IBBR) is connected to the mLDP domain on downstream 185 and a bier domain on the upstream. To connect the LDP domains via 186 BIER domain, IBBR needs to establish a targeted LDP session with EBBR 187 closest to the root of the P2MP or MP2MP LSP. To do so IBBR will 188 follow procedures in [RFC7060] in particular the section "6. targeted 189 mLDP with Multicast Tunneling". 191 The target LDP session can be established manually via configuration 192 or via automated mechanism. 194 3.1.1. Automatic tLDP session Creation 196 tLDP session can be signaled automatically from every IBBR to the 197 appropriate EBBR. When mLDP FEC arrives to IBBR from LDP domain, 198 IBBR can automatically start a tLDP Session to the EBBR closest to 199 the Root node. Both IBBR and EBBR should be in auto-discovery mode 200 and react to the arriving tLDP Signaling packets (i.e. targeted 201 hellos, keep- alives etc...) to establish the session automatically. 203 The Root node address in the mLDP FEC can be used to find the EBBR. 204 To identify the EBBR same procedures as [RFC7060] section 2.1 can be 205 used or the procedures as explained in the 206 [draft-ietf-bier-pim-signaling] appendix A. 208 3.1.2. ECMP Method on IBBR 210 If IBBR finds multiple equal cost EBBRs on the path to the Root, it 211 can use a vendor specific algorithm to choose between the EBBRs. 212 These algorithms are beyond the scope of this draft. As an example 213 the IBBR can use the smallest EBBR IP address to establish its mLDP 214 signaling to. 216 3.2. Egress BBR procedure 218 The Egress BBR (EBBR) is connected to the upstream mLDP domain. The 219 EBBR should accept the tLDP session generated form IBBR. It should 220 assign a unique "upstream assigned label" for each arriving FEC 221 generated by IBBRs. 223 The EBBR should follow the [RFC7060] procedures with following 224 modifications: 226 o The label assigned by EBBR cannot be Implicit Null. This is to 227 ensure that identity of each p2mp and/or mp2mp tunnel in BIER 228 domain is uniquely distinguished. 230 o The label can be assigned from a domain-wide Common Block (DCB) 231 [draft-ietf-bess-mvpn-evpn-aggregation-label] 233 o The Interface ID TLV, as per [RFC6389] should includes a new BIER 234 sub-domain sub- tlv (type TBD) 236 The EBBR will also generate a new label and FEC toward the ROOT on 237 the LDP domain. The EBBR Should stitch this generate label with the 238 "upstream assigned label" to complete the P2MP or MP2MP LSP. 240 With same token the EBBR should track all the arriving FECs and the 241 IBBRs that are generating these FECs. EBBR will use this information 242 to build the bier header for each set of common FEC arriving from the 243 IBBRs. 245 3.2.1. IBBR procedure for arriving upstream assigned label 247 Upon receiving the "upstream assigned label", IBBR should create its 248 own stitching instruction between the "upstream assigned label" and 249 the down stream signaled label. 251 4. Datapath Forwarding 253 4.1. Datapath traffic flow 255 On BFIR when the MPLS label for P2MP/MP2MP LSP arrives from upstream, 256 a lookup in ILM table is done and the label is swapped with tLDP 257 upstream assigned label. The BFIR will note all the BFERs that are 258 interested in specific P2MP/MP2MP LSP (as per section 3.2). BFIR 259 will put the corresponding BIER header with bit index set for all 260 IBBRs interested in this stream. BFIR will set the BIERHeader.Proto 261 = MPLS and will forward the BIER packet into BIER domain. 263 In the BIER domain normal BIER forwarding procedure will be done, as 264 per [RFC8279] 266 The BFERs will receive the BIER packet, will look at the protocol of 267 BIER header (MPLS). BFER will remove the BIER header and will do a 268 lookup in the ILM table for the upstream assigned label and perform 269 its corresponding action. 271 It should be noted that these procedures are also valid if BFIR is 272 the ILER and/or BFER is the ELER as per [RFC7060] 274 5. Recursive FEC 276 The above procedures also will work with a recursive FEC [RFC6512]. 277 The root used to determine the EBBR is the outer FECs root. The 278 entire recursive FEC needs to be preserve when it is forwarded via 279 tLDP and the label request. 281 6. IANA Consideration 283 1. A new BIER sub-domain sub- tlv for the interface ID TLV to be 284 assigned by IANA 286 7. Security Considerations 288 TBD 290 8. Acknowledgments 292 Acknowledgments Authors would like to acknowledge Jingrong Xie for 293 his comments and help on this draft. 295 9. Informative References 297 [draft-ietf-bess-mvpn-evpn-aggregation-label] 298 "Z. Zhang, E. Rosen, W.Lin, Z. Li, I. Wijnands " MVPN/EVPN 299 Tunnel Aggregation with Common Labels"", February 2012. 301 [draft-ietf-bier-pim-signaling] 302 "H.Bidgoli, F. Xu, J. Kotalwar, IJ. Wijnands, M. Mishra, 303 Z. Zhang "PIM Signaling Through BIER Core"", February 304 2012. 306 [RFC6388] "IJ. Wijnands, I. Minei, K. Kompella, B. Thomas "LDP 307 Extensions for P2MP and MP2MP"", Novermber 2011. 309 [RFC6389] "R. Aggarwal, JL. Le Roux "MPLS Upstream Label Assignment 310 for LDP"", November 2011. 312 [RFC6512] "IJ. Wijnands, E. Rosen, M. Napierala, N. Leymann "Using 313 Multipoint LDP when the backbone has No route to the 314 root"", February 2012. 316 [RFC7060] "M. Napierala, E. Rosen, IJ. Winjnands "Using LDP 317 Multipoint Extensions on Targeted LDP Sessions"", November 318 2013. 320 [RFC8279] "IJ. Wijnands, E. Rosen, A. Dolganow, T. Przygienda, S. 321 Aldrin "Multicast using BIER"", April 2018. 323 Authors' Addresses 324 Hooman Bidgoli (editor) 325 Nokia 326 Ottawa 327 Canada 329 Email: hooman.bidgoli@nokia.com 331 Jayant Kotalwar 332 Nokia 333 Montain View 334 US 336 Email: jayant.kotalwar@nokia.com 338 IJsbrand Wijnands 339 Cisco System 340 Diegem 341 Belgium 343 Email: ice@cisco.com 345 Mankamana Mishra 346 Cisco System 347 Milpitas 348 USA 350 Email: mankamis@cisco.com 352 Zhaohui Zhang 353 Juniper Networks 354 Boston 355 USA 357 Email: zzhang@juniper.com 359 Eddie Leyton 360 Verizon 362 Email: Edward.leyton@verizonwireless.com