idnits 2.17.1 draft-hb-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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. 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 3, 2019) is 1634 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 section? 'RFC2119' on line 109 looks like a reference -- Missing reference section? 'RFC6388' on line 195 looks like a reference -- Missing reference section? 'RFC7060' on line 244 looks like a reference -- Missing reference section? 'RFC 8279' on line 289 looks like a reference -- Missing reference section? 'RFC 7060' on line 297 looks like a reference Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Workgroup H. Bidgoli 3 Internet Draft J. Kotalwar 4 Intended status: Standard Track Nokia 5 Z.Zhang 6 Juniper Networks 7 Eddie Leyton 8 Vrizon 9 Mankamana Mishra 10 I. Wijanands 11 Cisco System, Inc. 13 Expires: May 6, 2020 November 3, 2019 15 M-LDP Signaling Through BIER Core 16 draft-hb-bier-mldp-signaling-over-bier-01 18 Abstract 20 Bit Index Explicit Replication (BIER) is an architecture that 21 provides multicast forwarding through a "BIER domain" without 22 requiring intermediate routers to maintain multicast related per-flow 23 state. Neither does BIER require an explicit tree-building protocol 24 for its operation. A multicast data packet enters a BIER domain at a 25 "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at 26 one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router 27 adds a BIER header to the packet. Such header contains a bit-string 28 in which each bit represents exactly one BFER to forward the packet 29 to. The set of BFERs to which the multicast packet needs to be 30 forwarded is expressed by the according set of bits switched on in 31 BIER packet header. 33 This document describes the procedure needed for mLDP tunnels to be 34 signaled over and stitched through a BIER core, allowing LDP routers 35 to run traditional Multipoint LDP services through a BIER core. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." The list 51 of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html 57 This Internet-Draft will expire on October 8, 2017. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Conventions used in this document . . . . . . . . . . . . . . . 3 78 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 79 3. mLDP Signaling Through BIER domain . . . . . . . . . . . . . . 4 80 3.1. Ingress BBR procedure . . . . . . . . . . . . . . . . . . . 5 81 3.1.1. Automatic tLDP session creation . . . . . . . . . . . . 5 82 3.1.1. ECMP Method on IBBR . . . . . . . . . . . . . . . . . . 6 83 3.2. Egress BBR procedure method . . . . . . . . . . . . . . . . 6 84 3.2.1. IBBR procedure upon arriving upstream assigned label . 6 85 4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . . 7 86 4.1. Datapath traffic flow . . . . . . . . . . . . . . . . . . . 7 87 5. Recursive FEC . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 92 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 93 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 96 1. Introduction 98 Some operators that are using mLDP P2MP LSPs for their multicast 99 transport would like to deploy BIER technology in some segment of 100 their network. This draft explains a method to signal mLDP services 101 and stitch the mLDP datapath labels through a BIER domain, with 102 minimal disruption and operational impact to the mLDP domain. 104 2. Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 2.1. Definitions 112 Some of the terminology specified in [I-D.draft-ietf-bier- 113 architecture-05] is replicated here and extended by necessary 114 definitions: 116 BIER: 118 Bit Index Explicit Replication (The overall architecture of 119 forwarding multicast using a Bit Position). 121 BFR: 123 Bit Forwarding Router (A router that participates in Bit Index 124 Multipoint Forwarding). A BFR is identified by a unique BFR- 125 prefix in a BIER domain. 127 BFIR: 129 Bit Forwarding Ingress Router (The ingress border router that 130 inserts the Bit Map into the packet). Each BFIR must have a 131 valid BFR-id assigned. BFIR is term used for dataplain packet 132 forwarding. 134 BFER: 136 Bit Forwarding Egress Router. A router that participates in 137 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each 138 BFER must have a valid BFR-id assigned. BFIR is term used for 139 dataplain packet forwarding. 141 BBR: 143 BIER Boundary router. The router between the LDP domain and 144 BIER domain. 146 IBBR: 148 Ingress BIER Boundary Router. The ingress router from 149 signaling point of view. It maintains mLDP adjacency toward 150 the LDP domain and determines if the mLDP FEC needs to be 151 signaled across the BIER domain via targeted ldp. 153 EBBR: 155 Egress BIER Boundary Router. The egress router in BIER domain 156 from signaling point of view. It terminates the targeted ldp 157 signaling through BIER domain. It also keeps track of all 158 IBBRs that are part of this p2mp tree 160 BFT: 162 Bit Forwarding Tree used to reach all BFERs in a domain. 164 BIFT: 166 Bit Index Forwarding Table. 168 BIER sub-domain: 170 A further distinction within a BIER domain identified by its 171 unique sub-domain identifier. A BIER sub-domain can support 172 multiple BitString Lengths. 174 BFR-id: 176 An optional, unique identifier for a BFR within a BIER sub- 177 domain. 179 3. mLDP Signaling Through BIER domain 180 bbr bbr 181 |---LDP Domain--|-----BIER domain-----|---LDP domain--| 182 S--( A )-----------( B ) ---- ( C ) ---- ( D )-----------( E )--h 184 ebbr ibbr 185 Sig <----MLDP------|<----targeted LDP----|<---MLDP------ 186 (new) 188 bfir bfer 189 ------------->|--------BIER-------->|-------------> Datapatah 190 (new) 192 Figure 1: bier boundary router 194 As per figure 1, point-to-multipoint and multipoint-to-multipoint 195 LSPs established via mLDP [RFC6388] can be signaled through a bier 196 domain via targeted LDP sessions. This procedure is explained in 197 [RFC7060] (Using LDP Multipoint Extension on Targeted LDP Sessions). 199 This documents provides some details and defines some needed 200 procedures. 202 3.1. Ingress BBR procedure 204 The Ingress BBR (IBBR) is connected to the mLDP on one side and a 205 bier domain on the other side. To connect the LDP domains via BIER 206 domain IBBR needs to establish a targeted LDP session with EBBR 207 closest to the root of the P2mp or mp2mp LSP. To do so IBBR will 208 follow procedures in [RFC7060] in particular the section "6. targeted 209 mLDP with Multicast Tunneling". 211 The target LDP session can be established manually via configuration 212 or via automated mechanism. 214 3.1.1. Automatic tLDP session creation 216 A tLDP session can be generated automatically from every IBBR to 217 EBBR. As an example when a mLDP FEC arrives on the IBBR, it can 218 automatically start a tLDP Session with the EBBR. In this case both 219 IBBR and EBBR should be in auto-discovery mode and react to the 220 arriving FEC or tLDP Signaling packets (i.e. targeted hellos, keep- 221 alives etc...). 223 The Root node address in the mLDP FEC can be used to find the EBBR. 224 To identify the EBBR same procedures as [RFC7060} section 2.1 can be 225 used or the procedures as explained in the [draft-ietf-bier-pim- 226 signaling] appendix A. After fining the IBBR the tLDP session can be 227 initiated from the IBBR to EBBR. 229 3.1.1. ECMP Method on IBBR 231 If IBBR finds multiple equal cost EBBRs on the path to the Root, it 232 can use a vendor specific algorithm to choose between the EBBRs. 233 These algorithms are beyond the scope of this draft. As an example 234 the IBBR can use the smallest EBBR IP address to establish its mLDP 235 signaling to. 237 3.2. Egress BBR procedure method 239 The Egress BBR (EBBR) is connected to the mLDP domain which the root 240 of the P2MP or MP2MP LSP resides on. The EBBR should accept the tLDP 241 session generated form IBBR. It should assign a unique "upstream 242 assigned label" for each arriving FEC generated by IBBRs. 244 The EBBR should follow the [RFC7060] procedures with following 245 modifications: 247 - The label assigned by EBBR cannot be Implicit Null. This is to 248 ensure that identity of each p2mp and/or mp2mp tunnel in BIER domain 249 is uniquely distinguished. 251 - The label can be assigned from a domain-wide Common Block (DCB) [I- 252 D.zzhang-bess-mvpn-evpn-aggregation-label], as well as upstream 253 assigned. 255 - The Interface ID TLV [RFC6389]includes a new BIER sub-domain sub- 256 tlv (type TBD) 258 The EBBR will also generate a new label and FEC toward the ROOT on 259 the mLDP domain. The EBBR Should stitch this generate label with the 260 "upstream assigned label" to complete the p2MP or MP2MP LSP. This 261 stitch point should be stored on the datapath (ILM) table for packet 262 forwarding. 264 With same token the EBBR should track all the arriving FECs and the 265 IBBRs that are generating these FECs. EBBR will use this information 266 to build the bier header for each set of common FEC arriving from the 267 IBBRs. 269 3.2.1. IBBR procedure upon arriving upstream assigned label 271 Upon receiving the "upstream assigned label", IBBR should create its 272 own stitching instruction between the "upstream assigned label" and 273 the down stream label that was signaled to it. IBBR should download 274 these instructions to the datapath. 276 4. Datapath Forwarding 278 4.1. Datapath traffic flow 280 On BFIR when the MPLS label for P2MP/MP2MP LSP arrives a lookup in 281 ILM table is done and the label is swapped with tLDP upstream 282 assigned label. The BFIR will note all the BFERs that are interested 283 in specific p2mp/mp2mp LSP (as per section 3.2). BFIR will put the 284 corresponding BIER header with bit index set for all IBBRs interested 285 in this P2MP LSP. BFIR will set the BIERHeader.Proto = MPLS and will 286 forward the BIER packet into BIER domain. 288 In the BIER domain normal BIER forwarding procedure will be done, as 289 per [RFC 8279] 291 The IBBRs will receive the BIER packet, will look at the protocol of 292 BIER header (MPLS). BFER will remove the BIER header and will do a 293 lookup in the ILM table for the upstream assigned label and perform 294 its corresponding action. 296 It should be noted that these procedures are valid if BFIR is the 297 ILER and/or BFER is the ELER as per [RFC 7060] 299 5. Recursive FEC 301 The above procedures also will work with a mLDP recursive FEC. The 302 root used to determine the EBBR is the outer root of the FEC. The 303 entire recursive FEC needs to be preserve when it is forwarded via 304 tLDP and the label request. 306 6. IANA Considerations 308 This document contains no actions for IANA. 310 7. Security Considerations 312 TBD 314 8. References 316 8.1. Normative References 318 [BIER_ARCH] Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 319 and S. Aldrin, "Multicast using Bit Index Explicit Replication", 320 internet-draft draft-ietf-bier-architecture-08, October 2016. 322 8.2. Informative References 324 [BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 325 Dolganow, A., and T. Przygienda, "Multicast VPN Using Bier", 326 internet-draft draft-ietf-bier-mvpn-08, January 2017. 328 [ISIS_BIER_EXTENSIONS] Ginsberg, L., Przygienda, T., Aldrin, S., and 329 Z. Zhang, "BIER Support via ISIS", internet-draft draft-ietf-bier- 330 isis-extensions-06.txt, March 2017. 332 [OSPF_BIER_EXTENSIONS] Psenak, P., Kumar, N., Wijnands, IJ., 333 Dolganow, A., Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF 334 Extensions for Bit Index Explicit Replication", internet-draft draft- 335 ietf-ospf-bier-extensions-09.txt, March 2017. 337 7. Acknowledgments Authors would like to acknowledge Jingrong Xie for 338 his comments and help on this draft. 340 Authors' Addresses 342 Hooman Bidgoli (editor) 343 Nokia 344 600 March Rd. 345 Ottawa, Ontario K2K 2E6 346 Canada 348 Email: hooman.bidgoli@nokia.com 350 Jayant Kotalwar 351 Nokia 352 380 N Bernardo Ave, 353 Mountain View, CA 94043 354 US 356 Email: jayant.kotalwar@nokia.com 358 Zhaohui Zhang 359 Juniper Networks 361 EMail: zzhang@juniper.net 363 IJsbrand Wijnands 364 Cisco Systems 366 EMail: ice@cisco.com 367 Eddie Leyton 368 Vrizon 370 Email: Edward.leyton@verizonwireless.com 372 Mankamana Mishra 373 Cisco System 374 821 alder drive 375 Milpitas California 376 USA 378 Email: mankamis@cisco.com