idnits 2.17.1 draft-hfa-bier-pim-signaling-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 (February 7, 2018) is 2267 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 139 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Workgroup H. Bidgoli, Ed. 3 Internet Draft A. Dolganow 4 Intended status: Standard Track J. Kotalwar 5 Nokia 6 Fengman Xu 7 Verizon 8 IJ. Wijnand 9 Cisco Systems, Inc. 10 Mankamana Mishra 11 Cisco System, Inc. 13 Expires: August 11, 2018 February 7, 2018 15 PIM Signaling Through BIER Core 16 draft-hfa-bier-pim-signaling-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 PIM Joins and Prunes 34 to be signaled through a BIER core. Allowing PIM routers to run 35 traditional PIM multicast 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) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. PIM Signaling Through BIER domain . . . . . . . . . . . . . . . 5 80 3.1. Ingress BBR procedure . . . . . . . . . . . . . . . . . . . 6 81 3.1.1. BIER packet construction at IBBR . . . . . . . . . . . 7 82 3.2. Signaling PIM through the BIER domain procedure . . . . . . 8 83 3.3 Procedure to determine EBBR on IBBR . . . . . . . . . . . . 8 84 3.3.1 EBBR identification via next-hop . . . . . . . . . . . . 8 85 3.3.1.1 Static Route . . . . . . . . . . . . . . . . . . . . 8 86 3.3.1.2 Interior Border Gateway Protocol (iBGP) . . . . . . 8 87 3.3.2 Route summarization at EBBR . . . . . . . . . . . . . . 9 88 3.3.4 Constrain shortest path first . . . . . . . . . . . . . 9 89 3.4. EBBR procedure . . . . . . . . . . . . . . . . . . . . . . 9 90 4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . . 10 91 4.1. BFIR tracking of (S,G) . . . . . . . . . . . . . . . . . . 10 92 4.2. Datapath traffic flow . . . . . . . . . . . . . . . . . . . 10 93 5. PIM-ASM behavior . . . . . . . . . . . . . . . . . . . . . . . 10 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 97 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 98 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 99 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 102 1. Introduction 104 Greenfield deployment of BIER might not be possible for some large 105 network. These networks deploy traditional PIM multicast services in 106 GRT or in mvpns such as multicast vpns rfc 6037. Typically, each 107 portion of these large networks have their own mandates and 108 requirements. 110 Consider the case of converged core, where single core is used for 111 fixed, business and wireless services. In this case there is a desire 112 for next generation "lean" core. Where a single IGP protocol or SDN 113 controller could enable unicast and multicast services. BIER is a 114 natural fit for this core. That said because of cost and operational 115 complexity the migration to BIER might fall into below categories: 117 1.Gradual migration of the network to BIER, starting with the 118 "lean" core and eventually to access networks. 120 2.Migrating only the core to BIER and keeping traditional pim 121 services in access. As an example, in wireless networks where there 122 are thousands of cell site routers. Each cell site router is a leaf 123 as such for scaling and cost it might be desired to keep 124 traditional PIM multicast services in the access network. 126 This draft explains the procedure to signal PIM joins and prunes 127 through a BIER core, as such enable provisioning of traditional pim 128 services through a BIER core. 130 It should be noted that this "lean" core is usually a single IGP 131 area. As such the procedures in this draft is concentrating on a 132 single BIER IGP area. 134 2. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 2.1. Definitions 142 Some of the terminology specified in [I-D. rfc8279] is replicated 143 here and extended by necessary definitions: 145 BIER: 147 Bit Index Explicit Replication (The overall architecture of 148 forwarding multicast using a Bit Position). 150 BFR: 152 Bit Forwarding Router (A router that participates in Bit Index 153 Multipoint Forwarding).A BFR is identified by a unique BFR- 154 prefix in a BIER domain. 156 BFIR: 158 Bit Forwarding Ingress Router (The ingress border router that 159 inserts the BM into the packet). Each BFIR must have a valid 160 BFR-id assigned. In this draft BIER will be used for 161 forwarding and tunneling of control plain packet (i.e. PIM) 162 and forwarding dataplane packets. BFIR is term used for 163 dataplane packet forwarding. 165 BFER: 167 Bit Forwarding Egress Router. A router that participates in 168 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each 169 BFER must have a valid BFR-id assigned. In this draft BIER 170 will be used for forwarding and tunneling of control plain 171 packet (i.e. PIM) and forwarding dataplain packets. BFIR is 172 term used for dataplain packet forwarding. 174 BBR: 176 BIER Boundary router. The router between the PIM domain and 177 BIER domain. Maintains PIM adjacency for all routers attached 178 to it on the PIM domain and terminates the PIM adjacency 179 toward the BIER domain. 181 IBBR: 183 Ingress BIER Boundary Router. The ingress router from 184 signaling point of view. It maintains PIM adjacency toward the 185 PIM domain and determines if PIM joins and prunes arriving 186 from PIM domain need to be signaled across the BIER domain. If 187 so it terminates the PIM adjacency toward the BIER domain and 188 signals the PIM joins/prunes through the BIER core. 190 EBBR: 192 Egress BIER Boundary Router. The egress router in BIER domain 193 from signaling point of view. It terminates the BIER packet 194 and forwards the signaled joins and prunes into PIM Domain. 196 BFT: 198 Bit Forwarding Tree used to reach all BFERs in a domain. 200 BIFT: 202 Bit Index Forwarding Table. 204 BIER sub-domain: 206 A further distinction within a BIER domain identified by its 207 unique sub-domain identifier. A BIER sub-domain can support 208 multiple BitString Lengths. 210 BFR-id: 212 An optional, unique identifier for a BFR within a BIER sub- 213 domain. 215 3. PIM Signaling Through BIER domain 217 bbr bbr 218 |--pim Domain--|-----bier domain-----|--pim domain--| 219 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 221 ebbr ibbr 222 Sig <-----PIM-----|<--Bier Tunneling----|<----PIM------ 223 (new) 225 bfir bfer 226 ------------->|--------BIER-------->|-------------> Datapatah 227 (no change) 229 Figure 1: bier boundary router 231 As per figure 1, the procedures of PIM signaling is done at the BIER 232 boundary router. The BIER boundary router (BBR) are connected to PIM 233 capable routers toward the pim domain and BIER routers toward the 234 bier domain. PIM routers in pim domain continue to send PIM state 235 messages to the BBR. The BBR will create pim adjacency between all 236 the PIM routers attach to it on the pim domain. That said the BBR 237 does not propagate all PIM packets natively into the BIER domain. 238 Instead when it determines that the PIM join or prune messages needs 239 to be signaled through the BIER domain it will tunnel the PIM packet 240 through BIER network. This tunneling is only done for signaling 241 purposes and not for creating a PIM adjacency between the two 242 disjoint pim domains through the bier domain. 244 The terminology ingress BBR (ibbr) and egress BBR (ebbr) are relative 245 from signaling point of view. 247 The ingress BBR will determine if an arriving pim join or prune needs 248 to be signaled across the bier domain. While the egress BBR will 249 determine if the bier packet is a signaling packet and propagate the 250 packet to its attach pim domain. 252 The BFER and BFIR are BBR from datapath point of view. It should be 253 noted the new procedures in this draft are only applicable to 254 signaling and there are no changes from datapath point of view. 256 3.1. Ingress BBR procedure 258 IBBR will create pim adjacency to all pim routers attach to it toward 259 the pim domain. 261 When a PIM join or prune for certain (S,G) arrives, the IBBR first 262 determines weather the join or prune is meant for a source that is 263 reachable through the bier domain. As an example, this source is 264 located on a disjoint PIM domain that is reachable through the BIER 265 domain. If so the ibbr will try to resolve the source via an ebbr 266 closest to the source. 268 The procedure to find the ebbr (BFIR from datapath point of view) can 269 be via many mechanisms explained in more detail in upcoming sections. 270 It should be noted that in most cases the BIER domain is a single IGP 271 area. The PIM domains are part of the same IGP area as BIER 272 domain(single area) or are stitched to the BIER domain via an ABR or 273 ASBR. in either case the BBRs are all located in the same area as 274 bier domain. Below are two examples of resolving ebbrs: 276 1.The ebbr can be an ABR or ASBR router in the same IGP area as bier 277 domain. In this case the ebbr summarizes the route to the source, 278 and as such the ebbr is the IGP source of this route. The IGP 279 source information can be used for identifying the ebbr and 280 resolving it. 282 2.If source and ebbr are within a single IGP area, the ebbr can be 283 resolved via SPF calculation. As an example, the closest ebbr to 284 the source. The ebbr BFR-ID is signaled via IGP to all BFRs, as 285 such making it possible to do SFP calculation. 287 After discovering the EBBR and its BFR-ID (flooded via IGP BIER 288 extension), the IBBR will construct the BIER header via the BIFT. The 289 signaling packet, in this case the PIM join/prune packet, is 290 encapsulated in the BIER header and transported through BIER domain 291 to EBBR. 293 On forwarding plane the IBBR will track all the PIM interfaces on the 294 attach pim domain which are interested in a certain (S,G). It creates 295 multicast states for arriving (S,G)s from pim domain, with incoming 296 interface (RPF) as BIER "tunnel" interface and outgoing interface as 297 the pim domain interface(s) on which PIM Join(s) were received on. If 298 there is another PIM Join for the same multicast (S,G) entry on 299 another interface arriving from pim domain, that interface gets added 300 in the outgoing interface list as well. 302 3.1.1. BIER packet construction at IBBR 304 The BIER header will be encoded with the BFR-id of the IBBR(with 305 appropriate bit set in the bitstring) and the PIM signaling packet is 306 then encapsulated in the packet. 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | BIFT-id | TC |S| TTL | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |Nibble | Ver | BSL | Entropy | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |OAM|Rsv| DSCP | Proto | BFIR-id | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | BitString (first 32 bits) ~ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 ~ ~ 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 ~ BitString (last 32 bits) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 BIERHeader.Proto = IPv4 or IPv6 325 BIERHeader.BitString= Bit corresponding to the BFR-ID of the EBBR 327 BIERHeader.BFIR-id = BFR-Id of the BER originating the encapsulated 328 PIM packet, i.e. the IBBR. 330 Rest of the values in the BIER header are determined based on the 331 network (MPLS/non-MPLS), capabilities (BSL), and network 332 configuration. 334 3.2. Signaling PIM through the BIER domain procedure 336 Throughout the BIER domain the BIER forwarding procedure is in par 337 with RFC 8279. No BIER router will examine the BIER packet 338 encapsulating the PIM signaling packet. As such there is no multicast 339 state build in the BIER domain. 341 The packet will be forwarded through the BIER domain until it reaches 342 the BER with matching BFR-ID as in the BIERHeader.Bitstring. This BER 343 (EBBR) will remove the BIER header and examine the PIM IPv4 or IPv6 344 signaling packet farther. 346 3.3 Procedure to determine EBBR on IBBR 348 As it was explained in previous section, IBBR needs to determine the 349 EBBR closest to the source. This is needed to encode the BIER header 350 BitString field for forwarding of the signaling packet. There can be 351 many mechanism to determine the EBBR. This section explain some 352 routing methods that can be used to achieve this. 354 3.3.1 EBBR identification via next-hop 356 Assuming on the IBBR the source is resolved via EBBR bier prefix-id 357 as its next-hop, the next-hop can be used to lookup the EBBR bit- 358 index via the BIFT. In most cases the bier prefix-id is a loopback 359 address. The next-hop of the source on IBBR can be set to EBBR via 360 multiple methods, including Static Route and BGP. 362 3.3.1.1 Static Route 364 On IBBR there can be a static route configured for the source, with 365 source next-hop set as EBBR BIER prefix id. 367 3.3.1.2 Interior Border Gateway Protocol (iBGP) 369 Consider the following topology: 371 bbr bbr 372 ebbr ibbr 373 |--pim Domain--|-----bier domain-----|--pim domain--| 374 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h 376 Figure 2 378 Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM 379 Domain routes are redistributed to the BIER domain via BGP. This 380 would include the Multicast Source IP address (S), which resides in 381 the PIM Domain. In such case BGP should use the same loopback 382 interface as its next-hop as the BBR prefix-id. This will ensure that 383 all PIM domain routes, including the Multicast Source IP address (S) 384 are resolve via BBR's bier prefix id as thier next-hop. When the host 385 (h) triggers a PIM join message to IBBR (D), IBBR tries to resolve 386 (S). It resolves (S) via BGP installed route and realizes its next- 387 hop is EBBR (B). IBBR will use this next-hop (B) to do a lookup in 388 the BIFT and find its corresponding BIER bit index in the BIFT. Next 389 IBBR will build the BIER header with corresponding EBBR bit index and 390 tunnel the PIM signaling message toward EBBR. This procedure is 391 inline with RFC6826 mLDP in-band signaling section 2. 393 3.3.2 Route summarization at EBBR 395 The BIER domain can be an IGP area, in this case the EBBRs and IBBRs 396 would act as an area boundary router (ABR). ABR could summarize 397 routes and/or generate new routes with advertising router field set 398 to EBBR bier prefix-id. When IBBR resolves the Source it can use the 399 advertising router field to generate the BIER BitString Header for 400 the EBBR closest to the source. 402 3.3.4 Constrain shortest path first 404 In the BIER domain the edge BIER routers use IGP or BGP to advertise 405 BIER extension TLVs. As such the routing protocols have a view of the 406 EBBR closest to the source in PIM domain. To find the EBBR, IBBR can 407 do a lookup for the source and ask for the closest EBBR on the path 408 to the source. This look up can be a CSPF lookup. The IGP should 409 return the EBBR closest to the source as part of this lookup. 411 3.4. EBBR procedure 413 After receiving the BIER packet and determining this packet is a 414 signaling packet. As such the EBBR will remove the BIER header from 415 PIM packet and does a route lookup for the source of the pim packet, 416 if the source is on a local attach pim domain, it forwards the PIM 417 packet toward the source. 419 With same token the EBBR creates a multicast state with incoming 420 interface as same interface that PIM join packet was forwarded and 421 outgoing interfaces of BIER tunnel with BIER-Header.BFIR-id as one of 422 the BFER of the tunnel. 424 The EBBR will also build a BIER reverse path forwarding table, using 425 the BIERHeader.BFIR-id and the arriving PIM packet (S,G). This is 426 explained in section 4.1. 428 It should be noted EBBR will maintain PIM adjacency toward the PIM 429 domain and all PIM routers which are connected to it. 431 At this point the end-to-end multicast traffic flow setup is 432 complete. 434 4. Datapath Forwarding 436 4.1. BFIR tracking of (S,G) 438 For a specific Source and Group, BFIR (EBBR)should track all the 439 interested BFERs via arriving PIM signaling from BIER Domain. BFIR 440 should build its multicast tree with incoming interface (IIF) as PIM 441 interface (in PIM domain) and out going interfaces OIFs set as the 442 of the interested BFERs (in BIER Domain). 444 4.2. Datapath traffic flow 446 When the multicast data traffic arrives on the BFIR (EBBR) the router 447 will find all the interested BFERs for that specific (S,G). The 448 router then constructs the BIERHeader.BitString with all the BFER 449 interested in the group and will forward the packet to the BIER 450 domain. The BFER(s) will accept the packets and remove the BIER 451 header and forward the multicast packet as per pre-build multicast 452 state for (G) and its outgoing interfaces. 454 5. PIM-ASM behavior 456 In case of PIM ASM the procedure for LEAFs joining RP is same as 457 above. The unicast (source registration) traffic from source to RP 458 will be flooded throughout the BIER domain as regular unicast traffic 459 without BIER involvement. 461 6. IANA Considerations 463 This document contains no actions for IANA. 465 7. Security Considerations 467 TBD 469 8. References 471 8.1. Normative References 473 [BIER_ARCH] Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 474 and S. Aldrin, "Multicast using Bit Index Explicit Replication", rfc 475 8279, October 2016. 477 8.2. Informative References 479 [BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 480 Dolganow, A., and T. Przygienda, "Multicast VPN Using Bier", 481 internet-draft draft-ietf-bier-mvpn-08, January 2017. 483 [ISIS_BIER_EXTENSIONS] Ginsberg, L., Przygienda, T., Aldrin, S., and 484 Z. Zhang, "BIER Support via ISIS", internet-draft draft-ietf-bier- 485 isis-extensions-06.txt, March 2017. 487 [OSPF_BIER_EXTENSIONS] Psenak, P., Kumar, N., Wijnands, IJ., 488 Dolganow, A., Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF 489 Extensions for Bit Index Explicit Replication", internet-draft draft- 490 ietf-ospf-bier-extensions-09.txt, March 2017. 492 7. Acknowledgments 494 Authors' Addresses 496 Hooman Bidgoli (editor) 497 Nokia 498 600 March Rd. 499 Ottawa, Ontario K2K 2E6 500 Canada 502 Email: hooman.bidgoli@nokia.com 504 Fengman Xu 505 Verizon 506 400 International PKWY 507 Richardson, Tx 75081 508 US 510 Email: fengman.xu@verizon.com 512 Jayant Kotalwar 513 Nokia 514 380 N Bernardo Ave, 515 Mountain View, CA 94043 516 US 518 Email: jayant.kotalwar@nokia.com 520 Andrew Dolganow 521 Nokia 522 750D Chai Chee Rd 523 06-06, Viva Business Park 524 Singapore 469004 526 Email: Andrew.dolganow@nokia.com 528 IJsbrand Wijnands 529 Cisco Systems, Inc. 530 De Kleetlaan 6a 531 Diegem 1831 532 Belgium 534 Email: ice@cisco.com 536 Mankamana Mishra 537 mankamis@cisco.com 538 821 alder drive, 539 Milpitas California 540 USA 542 Email: mankamis@cisco.com