idnits 2.17.1 draft-zwzw-bier-prefix-redistribute-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 23, 2019) is 1676 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) == Outdated reference: A later version (-10) exists of draft-ietf-bier-idr-extensions-07 == Outdated reference: A later version (-07) exists of draft-ietf-bier-ospfv3-extensions-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Zheng. Zhang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track Bo. Wu 5 Expires: March 26, 2020 Individual 6 Zhaohui. Zhang 7 Juniper Networks 8 IJsbrand. Wijnands 9 Cisco Systems, Inc. 10 September 23, 2019 12 BIER Prefix Redistribute 13 draft-zwzw-bier-prefix-redistribute-03 15 Abstract 17 This document defines a BIER proxy function to interconnect different 18 underlay routing protocol areas in a network. And a new BIER proxy 19 range sub-TLV is also defined to convey BIER BFR-id information 20 across the routing areas. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC2119. 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 March 26, 2020. 45 Copyright Notice 47 Copyright (c) 2019 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. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. BIER proxy range sub-TLV . . . . . . . . . . . . . . . . 6 66 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Problem statement 74 +-------------------------------------------------------+ 75 | +----+ +----+ PIM | 76 | +----+ R1 +-------------+ R2 +-----+ | 77 | | +----+ +----+ | | 78 | | | | 79 | | OSPF area 0 / ISIS | | 80 | | | | 81 | | +----+ +----+ | | 82 | +-----+ +------------+ +-----+ | 83 | +------------+ R3 +---+ +---+ R4 +------------+ | 84 | | +----+ | | +----+ | | 85 | | | | | | 86 | | OSPF area 1 | | OSPF area 2 | | 87 | | | | | | 88 | | +----+ +----+ | | +----+ +----+ | | 89 | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | 90 | +----+ +----+ +----+ +----+ | 91 +-------------------------------------------------------+ 92 Figure 1 94 Figure 1 shows that there are three areas in a traditional network. 95 In some deployment situations, different routing protocols may also 96 be used in a network. There are just small number of routers in each 97 area of the network. Currently, multicast services are provided in 98 this hybrid network by using protocol independent feature of PIM. 100 BIER could be a candidate multicast protocol to replace PIM to reduce 101 multicast states in the hybrid network. BIER [RFC8279] is a new 102 architecture for the forwarding of multicast data packets. It does 103 not require a protocol for explicitly building multicast distribution 104 trees, nor does it require intermediate nodes to maintain any per- 105 flow state. In order to build BIER forwarding plane, BIER key 106 parameters must be flooded in one BIER domain such as BFR-prefix, 107 BFR-id, subdomain-id, and so on. The routing protocols which are 108 used to flood these BIER parameters are called BIER routing underlay. 109 The associated routing protocol extensions are defined in documents 110 such as [RFC8401], [RFC8444], [I-D.ietf-bier-idr-extensions], 111 [I-D.ietf-bier-ospfv3-extensions], and so on. 113 +----+ +----+ 114 +----+ R1 +-------------+ R2 +-----+ 115 | +----+ +----+ | 116 | OSPF / ISIS | 117 | BIER domain 1 | 118 | | 119 | +----+ +----+ | 120 +-----+ +------------+ +-----+ 121 +------------+ R3 +---+ +---+ R4 +------------+ 122 | +----+ | | +----+ | 123 | OSPF | | OSPF | 124 | | | | 125 | BIER domain 2 | | BIER domain 3 | 126 | +----+ +----+ | | +----+ +----+ | 127 +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ 128 +----+ +----+ +----+ +----+ 129 Figure 2 131 Based on the BIER design, a BIER domain is limited by the underlay 132 routing protocols flooding scope. As in a hybrid network depicted in 133 figure 2, in case we want deploy BIER instead of PIM, there are 134 several BIER domains because of different underlay routing protocols 135 limitation. Multiple encapsulating/ decapsulation executions are 136 needed to across multiple BIER domains. These executions slow down 137 the forwarding efficiency. The border routers also need to maintain 138 overlay state, which is undesired. 140 Except the hybrid network, there is the situation that several areas 141 formed by one same IGP protocol need to be merged into one BIER 142 domain in existing network. The prefix redistribution method defined 143 in this document can be used too. 145 2. Proposal 146 +-------------------------------------------------------+ 147 | +----+ +----+ BIER | 148 | +----+ R1 +-------------+ R2 +-----+ domain 1 | 149 | | +----+ +----+ | | 150 | | OSPF/ISIS | | 151 | | | | 152 | | +----+ +----+ | | 153 | +-----+ +------------+ +-----+ | 154 | +------------+ R3 +---+ +---+ R4 +------------+ | 155 | | +----+ | | +----+ | | 156 | | | | | | 157 | | OSPF area 1 | | OSPF area 2 | | 158 | | | | | | 159 | | +----+ +----+ | | +----+ +----+ | | 160 | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | 161 | +----+ +----+ +----+ +----+ | 162 +-------------------------------------------------------+ 163 Figure 3 165 It is more efficient to deploy BIER by creating one BIER domain for 166 the hybrid network to achieve forwarding benefit. 168 Since the limitation of the BIER routing protocol scope, BFR-id is 169 confined to only one routing area. A BIER proxy function is 170 introduced to transport BIER BFR-id information in a BIER domain 171 across multiple routing protocol areas. So BIER forwarding tables 172 can be built across multiple underlay routing protocols to replace 173 encapsulation/decapsulation processing. In the current deployment, 174 border router (ABR) has a similar role, ABR summaries unicast routing 175 information from one routing protocol area and sends it to another 176 routing area by new routing protocol messages. So ABR can implement 177 BIER proxy function to summarize BIER BFR-id information from one 178 routing protocol area and sends it to another routing area. 180 In figure 3, R3 and R4 connect two areas which running different 181 routing protocols, they can be used as BIER proxies to transport BIER 182 information. For example, after R3 receives BFR-ids information from 183 OSPF area 1 and sends it to ISIS routing area, the routers in ISIS 184 routing area can generate BIER forwarding items toward the BFR-ids in 185 OSPF area 1. Similarly, R3 receives BFR-ids information from ISIS 186 area and sends it to OSPF area 1, the routers in OSPF area 1 can 187 build BIER forwarding items toward the BFR-ids in ISIS area. R4 does 188 the same function, the BIER forwarding plane is constructed 189 accordingly. 191 3. Advertisement 193 According to [RFC8279], each BFER needs to have a unique (in each 194 sub-domain) BFR-id, and each BFR and BFER floods itself BIER info 195 sub-TLV and associated sub-sub-TLVs in the BIER domain. To keep 196 consistent with the definition in [RFC8444], 197 [I-D.ietf-bier-ospfv3-extensions], and [RFC8401], BIER info sub-TLV 198 defined in [RFC8401] and BIER sub-TLV defined in [RFC8444], 199 [I-D.ietf-bier-ospfv3-extensions] is reused to convey the BFR-id 200 information. OSPF extended Prefix Opaque LSA [RFC7684] and TLVs 235, 201 237 defined in [RFC5120], or TLVs 135 [RFC5305], or TLV 236 [RFC5308] 202 are still used to carry the BFR-id / BFR-prefix information. 204 The key parameters got from the original routing protocol should be 205 adapted to the format of next routing protocol, such as BFR-prefix, 206 BFR-id, subdomain-id, and so on. Some parameters like BAR, MT-ID has 207 local significance, So they should be set to same values with BIER 208 proxy own advertisement when BIER proxy advertise them to the next 209 routing area. 211 And as the two BIER info sub-sub-TLVs (sub-TLVs) including MPLS 212 encapsulation and BSL conversion also have local significance. The 213 information carried in these two sub-sub-TLV need not, but MAY, be 214 advertised to next routing area. 216 3.1. BIER proxy range sub-TLV 218 In case unicast default route and aggregated / summarized routes are 219 used in some routing areas and routers in next area can not see the 220 specific BFR-prefix routes from original area, the prefix advertised 221 should be set to default route or aggregated / summarized routes. 222 Like in figure 3, in case R3/R4 does not advertise specific ISIS 223 unicast routes to OSPF area and only advertises unicast default route 224 or aggregated / summarized route to OSPF area 1/2, when R3/R4 225 advertises BIER info sub-TLV to OSPF area 1/2, R3 MUST advertise the 226 prefix with default route or aggregated / summarized route. In that 227 case, multiple BFR-ids will be mapped to one prefix. In order to 228 advertise BFR-ids optimally, we define a new BIER proxy range sub-TLV 229 to advertise the information of BFR-ids. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Type | Length | subdomain-id | resv | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | BFR-id | BFR-id range | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 o Type: TBD to indicate the BIER proxy range sub-TLV. 241 o Length: variable. 243 o Subdomain-id: The subdomain-id from original advertisement. 245 o resv: The reserved field. 247 o BFR-id: The first BFR-id from original advertisement. 249 o BFR-id range: The range of BFR-ids with one subdomain-id. 251 The BIER proxy range sub-TLV is attached to the aggregated / 252 summarized route prefix or default route prefix. The summarized / 253 aggregated / default prefix may need multiple BIER proxy range sub- 254 TLVs if the BFR-ids covered by the prefix are allocated from 255 different ranges (even if they're from a single range but if some 256 BFR-ids in the range map to some BIER prefixes that are covered by a 257 different summarized / aggregated prefix, then that single large 258 range needs to be broken into smaller ranges). 260 The BFR-ids associated with the summarized prefix can be advertised 261 individally in the BIER range sub-TLV. Though BFR-id's range can 262 increase advertisement efficiency, necessary configuration / policy 263 should be provided to guide the range generation of BFR-ids. 264 Otherwise unwanted amount of updates may occur when a BFR-id is 265 removed from the range. 267 Because a summarized / default prefix covers many BIER prefixes, the 268 mapping between a BIER prefix and its BFR-id is no longer conveyed in 269 the routing underlay. As a result, the mapping must be provided by 270 other means, e.g. in the multicast overlay. 272 4. Example 274 As in figure 3, R3 and R4 as BIER proxy, R3 as an example should 275 advertise the BIER BFR-ids information from ISIS area to OSPF area 1 276 with the advertiser set to R3 itself, and advertise BIER info from 277 OSPF area 1 to ISIS area as well. In case R3 and R4 generates 278 specific BFR-prefix and BFR-ids from the original area to the next 279 area, BIER info sub-TLV defined in [RFC8401] and BIER sub-TLV defined 280 in [RFC8444], or [I-D.ietf-bier-ospfv3-extensions] is reused to 281 convey the BFR-id information. All the routers generate BIER 282 forwarding items to other area toward BIER proxy according to 283 [RFC8279]. 285 In case BIER proxy can not advertise specific BFR-prefix but 286 aggregated / summarized / default prefix from the original area to 287 the next area, BIER proxy range sub-TLV is used to convey the 288 information. Suppose that Rm is an ingress router, R1, R2, Rx and Ry 289 is egress router, the BFR-ids of these egress router are 31, 55, 112, 290 157. The BFR prefixes of them are 10.1.1.5, 10.1.1.50, 203.1.1.10, 291 203.1.1.60. Suppose that summarized prefixes are advertised into 292 OSPF area. The summarized prefixes are 10.1.1.0/24 and 203.1.1.0/24. 293 All the routers in OSPF area 1 compute forwarding table for unicast / 294 BIER according to the summarized prefixes, and they can get to these 295 prefixes by routes toward proxy R3. 297 Rm encapsulate multicast flow with BIER header that with 31, 55, 112 298 and 157 bit set in the BIER header (Supposed that 256 BitStringLength 299 is used). The routers in OSPF area 1 forward packet toward R3. R3 300 forwards packet according to the BFR-ids set in the BIER header 301 normally. Later packet reaches R1, R2 and R4. Similarly, R4 302 forwards packet into OSPF area 2 normally. Finally packet reaches Rx 303 and Ry. 305 5. IANA Considerations 307 IANA is requested to set up a new types of sub-TLV (TLV) registry 308 value for BIER proxy range advertisement in OSPF, ISIS, BGP, etc. 310 6. Security Considerations 312 Implementations must assure that malformed TLV and Sub-TLV 313 permutations do not result in errors which cause hard protocol 314 failures. 316 7. Acknowledgements 318 The authors would like to thank Stig Venaas for his valuable comments 319 and suggestions. 321 8. Normative References 323 [I-D.ietf-bier-idr-extensions] 324 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 325 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 326 idr-extensions-07 (work in progress), September 2019. 328 [I-D.ietf-bier-ospfv3-extensions] 329 Psenak, P., Kumar, N., and I. Wijnands, "OSPFv3 Extensions 330 for BIER", draft-ietf-bier-ospfv3-extensions-00 (work in 331 progress), May 2019. 333 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 334 Topology (MT) Routing in Intermediate System to 335 Intermediate Systems (IS-ISs)", RFC 5120, 336 DOI 10.17487/RFC5120, February 2008, 337 . 339 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 340 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 341 2008, . 343 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 344 DOI 10.17487/RFC5308, October 2008, 345 . 347 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 348 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 349 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 350 2015, . 352 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 353 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 354 Explicit Replication (BIER)", RFC 8279, 355 DOI 10.17487/RFC8279, November 2017, 356 . 358 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 359 Zhang, "Bit Index Explicit Replication (BIER) Support via 360 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 361 . 363 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 364 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 365 Extensions for Bit Index Explicit Replication (BIER)", 366 RFC 8444, DOI 10.17487/RFC8444, November 2018, 367 . 369 Authors' Addresses 371 Zheng(Sandy) Zhang 372 ZTE Corporation 374 EMail: zzhang_ietf@hotmail.com 376 Bo Wu 377 Individual 379 EMail: w1973941761@163.com 380 Zhaohui Zhang 381 Juniper Networks 383 EMail: zzhang@juniper.net 385 IJsbrand Wijnands 386 Cisco Systems, Inc. 388 EMail: ice@cisco.com