idnits 2.17.1 draft-zwzw-bier-prefix-redistribute-02.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 (March 10, 2019) is 1874 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-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Zheng. Zhang 3 Internet-Draft Bo. Wu 4 Intended status: Standards Track ZTE Corporation 5 Expires: September 11, 2019 Zhaohui. Zhang 6 Juniper Networks 7 IJsbrand. Wijnands 8 Cisco Systems, Inc. 9 March 10, 2019 11 BIER Prefix Redistribute 12 draft-zwzw-bier-prefix-redistribute-02 14 Abstract 16 This document defines a BIER proxy function to interconnect different 17 underlay routing protocol areas in a hybrid network. And a new BIER 18 proxy range sub-TLV is also defined to convey BIER BFR-id information 19 across the routing areas. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC2119. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 11, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. BIER proxy range sub-TLV . . . . . . . . . . . . . . . . 6 65 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Problem statement 73 +-------------------------------------------------------+ 74 | | 75 | +----+ +----+ PIM | 76 | +----+ R1 +-------------+ R2 +-----+ | 77 | | +----+ +----+ | | 78 | | | | 79 | | ISIS | | 80 | | | | 81 | | | | 82 | | | | 83 | | +----+ +----+ | | 84 | +-----+ +------------+ +-----+ | 85 | +------------+ R3 +---+ +---+ R4 +------------+ | 86 | | +----+ | | +----+ | | 87 | | | | | | 88 | | | | | | 89 | | OSPF area 1 | | OSPF area 2 | | 90 | | | | | | 91 | | +----+ +----+ | | +----+ +----+ | | 92 | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | 93 | +----+ +----+ +----+ +----+ | 94 | | 95 +-------------------------------------------------------+ 96 Figure 1 98 Figure 1 shows a hybrid network with different IGP routing protocols 99 deployed. Hybrid network is used mostly for management 100 consideration. There are just small number of routers in each area 101 of the network. Currently, multicast services are provided in this 102 hybrid network by using protocol independent feature of PIM. 104 BIER could be a candidate multicast protocol to replace PIM to reduce 105 multicast states in the hybrid network. BIER [RFC8279] is a new 106 architecture for the forwarding of multicast data packets. It does 107 not require a protocol for explicitly building multicast distribution 108 trees, nor does it require intermediate nodes to maintain any per- 109 flow state. In order to build BIER forwarding plane, BIER key 110 parameters must be flooded in one BIER domain such as BFR-prefix, 111 BFR-id, subdomain-id, and so on. The routing protocols which are 112 used to flood these BIER parameters are called BIER routing underlay. 113 The associated routing protocol extensions are defined in documents 114 such as [RFC8401], [RFC8444], [I-D.ietf-bier-idr-extensions], and so 115 on. 117 +----+ +----+ 118 +----+ R1 +-------------+ R2 +-----+ 119 | +----+ +----+ | 120 | | 121 | ISIS | 122 | | 123 | BIER domain 1 | 124 | | 125 | +----+ +----+ | 126 +-----+ +------------+ +-----+ 127 +------------+ R3 +---+ +---+ R4 +------------+ 128 | +----+ | | +----+ | 129 | | | | 130 | OSPF | | OSPF | 131 | | | | 132 | BIER domain 2 | | BIER domain 3 | 133 | +----+ +----+ | | +----+ +----+ | 134 +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ 135 +----+ +----+ +----+ +----+ 136 Figure 2 138 Based on the BIER design, a BIER domain is limited by the underlay 139 routing protocols flooding scope. As in a hybrid network depicted in 140 figure 2, in case we want deploy BIER instead of PIM, there are 141 several BIER domains because of different underlay routing protocols 142 limitation. Multiple encapsulating/ decapsulation executions are 143 needed to across multiple BIER domains. These executions slow down 144 the forwarding efficiency. The border routers also need to maintain 145 overlay state, which is undesired. 147 Except the hybrid network, there is the situation that several areas 148 formed by one same IGP protocol need to be merged into one BIER 149 domain in existing network. The prefix redistribution method defined 150 in this document can be used too. 152 2. Proposal 153 +-------------------------------------------------------+ 154 | | 155 | +----+ +----+ BIER | 156 | +----+ R1 +-------------+ R2 +-----+ domain 1 | 157 | | +----+ +----+ | | 158 | | | | 159 | | ISIS | | 160 | | | | 161 | | | | 162 | | +----+ +----+ | | 163 | +-----+ +------------+ +-----+ | 164 | +------------+ R3 +---+ +---+ R4 +------------+ | 165 | | +----+ | | +----+ | | 166 | | | | | | 167 | | | | | | 168 | | OSPF area 1 | | OSPF area 2 | | 169 | | | | | | 170 | | +----+ +----+ | | +----+ +----+ | | 171 | +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ | 172 | +----+ +----+ +----+ +----+ | 173 | | 174 +-------------------------------------------------------+ 175 Figure 3 177 It is more efficient to deploy BIER by creating one BIER domain for 178 the hybrid network to achieve forwarding benefit. 180 Since the limitation of the BIER routing protocol scope, BFR-id is 181 confined to only one routing area. A BIER proxy function is 182 introduced to transport BIER BFR-id information in a BIER domain 183 across multiple routing protocol areas. So BIER forwarding tables 184 can be built across multiple underlay routing protocols to replace 185 encapsulation/decapsulation processing. In the current deployment, 186 border router (ABR) has a similar role, ABR summaries unicast routing 187 information from one routing protocol area and sends it to another 188 routing area by new routing protocol messages. So ABR can implement 189 BIER proxy function to summarize BIER BFR-id information from one 190 routing protocol area and sends it to another routing area. 192 In figure 3, R3 and R4 connect two areas which running different 193 routing protocols, they can be used as BIER proxies to transport BIER 194 information. For example, after R3 receives BFR-ids information from 195 OSPF area 1 and sends it to ISIS routing area, the routers in ISIS 196 routing area can generate BIER forwarding items toward the BFR-ids in 197 OSPF area 1. Similarly, R3 receives BFR-ids information from ISIS 198 area and sends it to OSPF area 1, the routers in OSPF area 1 can 199 build BIER forwarding items toward the BFR-ids in ISIS area. R4 does 200 the same function, the BIER forwarding plane is constructed 201 accordingly. 203 3. Advertisement 205 According to [RFC8279], each BFER needs to have a unique (in each 206 sub-domain) BFR-id, and each BFR and BFER floods itself BIER info 207 sub-TLV and associated sub-sub-TLVs in the BIER domain. To keep 208 consistent with the definition in [RFC8444] and [RFC8401], BIER info 209 sub-TLV defined in [RFC8401] and BIER sub-TLV defined in [RFC8444] is 210 reused to convey the BFR-id information. OSPF extended Prefix Opaque 211 LSA [RFC7684] and TLVs 235, 237 defined in [RFC5120] are still used 212 to carry the BFR-id / BFR-prefix information. 214 The key parameters got from the original routing protocol should be 215 adapted to the format of next routing protocol, such as BFR-prefix, 216 BFR-id, subdomain-id, and so on. Some parameters like BAR, MT-ID has 217 local significance, So they should be set to same values with BIER 218 proxy own advertisement when BIER proxy advertise them to the next 219 routing area. 221 And as the two BIER info sub-sub-TLVs (sub-TLVs) including MPLS 222 encapsulation and BSL conversion also have local significance. The 223 information carried in these two sub-sub-TLV need not, but MAY, be 224 advertised to next routing area. 226 3.1. BIER proxy range sub-TLV 228 In case unicast default route and aggregated / summarized routes are 229 used in some routing areas and routers in next area can not see the 230 specific BFR-prefix routes from original area, the prefix advertised 231 should be set to default route or aggregated / summarized routes. 232 Like in figure 3, in case R3/R4 does not advertise specific ISIS 233 unicast routes to OSPF area and only advertises unicast default route 234 or aggregated / summarized route to OSPF area 1/2, when R3/R4 235 advertises BIER info sub-TLV to OSPF area 1/2, R3 MUST advertise the 236 prefix with default route or aggregated / summarized route. In that 237 case, multiple BFR-ids will be mapped to one prefix. In order to 238 advertise BFR-ids optimally, we define a new BIER proxy range sub-TLV 239 to advertise the information of BFR-ids. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type | Length | subdomain-id | resv | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | BFR-id | BFR-id range | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 o Type: TBD to indicate the BIER proxy range sub-TLV. 251 o Length: variable. 253 o Subdomain-id: The subdomain-id from original advertisement. 255 o resv: The reserved field. 257 o BFR-id: The first BFR-id from original advertisement. 259 o BFR-id range: The range of BFR-ids with one subdomain-id. 261 The BIER proxy range sub-TLV is attached to the aggregated / 262 summarized route prefix or default route prefix. The summarized / 263 aggregated / default prefix may need multiple BIER proxy range sub- 264 TLVs if the BFR-ids covered by the prefix are allocated from 265 different ranges (even if they're from a single range but if some 266 BFR-ids in the range map to some BIER prefixes that are covered by a 267 different summarized / aggregated prefix, then that single large 268 range needs to be broken into smaller ranges). 270 The BFR-ids associated with the summarized prefix can be advertised 271 individally in the BIER range sub-TLV. Though BFR-id's range can 272 increase advertisement efficiency, necessary configuration / policy 273 should be provided to guide the range generation of BFR-ids. 274 Otherwise unwanted amount of updates may occur when a BFR-id is 275 removed from the range. 277 Because a summarized / default prefix covers many BIER prefixes, the 278 mapping between a BIER prefix and its BFR-id is no longer conveyed in 279 the routing underlay. As a result, the mapping must be provided by 280 other means, e.g. in the multicast overlay. 282 4. Example 284 As in figure 3, R3 and R4 as BIER proxy, R3 as an example should 285 advertise the BIER BFR-ids information from ISIS area to OSPF area 1 286 with the advertiser set to R3 itself, and advertise BIER info from 287 OSPF area 1 to ISIS area as well. In case R3 and R4 generates 288 specific BFR-prefix and BFR-ids from the original area to the next 289 area, BIER info sub-TLV defined in [RFC8401] and BIER sub-TLV defined 290 in [RFC8444] is reused to convey the BFR-id information. All the 291 routers generate BIER forwarding items to other area toward BIER 292 proxy according to [RFC8279]. 294 In case BIER proxy can not advertise specific BFR-prefix but 295 aggregated / summarized / default prefix from the original area to 296 the next area, BIER proxy range sub-TLV is used to convey the 297 information. Suppose that Rm is an ingress router, R1, R2, Rx and Ry 298 is egress router, the BFR-ids of these egress router are 31, 55, 112, 299 157. The BFR prefixes of them are 10.1.1.5, 10.1.1.50, 203.1.1.10, 300 203.1.1.60. Suppose that summarized prefixes are advertised into 301 OSPF area. The summarized prefixes are 10.1.1.0/24 and 203.1.1.0/24. 302 All the routers in OSPF area 1 compute forwarding table for unicast / 303 BIER according to the summarized prefixes, and they can get to these 304 prefixes by routes toward proxy R3. 306 Rm encapsulate multicast flow with BIER header that with 31, 55, 112 307 and 157 bit set in the BIER header (Supposed that 256 BitStringLength 308 is used). The routers in OSPF area 1 forward packet toward R3. R3 309 forwards packet according to the BFR-ids set in the BIER header 310 normally. Later packet reaches R1, R2 and R4. Similarly, R4 311 forwards packet into OSPF area 2 normally. Finally packet reaches Rx 312 and Ry. 314 5. IANA Considerations 316 IANA is requested to set up a new types of sub-TLV (TLV) registry 317 value for BIER proxy range advertisement in OSPF, ISIS, BGP, etc. 319 6. Security Considerations 321 Implementations must assure that malformed TLV and Sub-TLV 322 permutations do not result in errors which cause hard protocol 323 failures. 325 7. Acknowledgements 327 The authors would like to thank Stig Venaas for his valuable comments 328 and suggestions. 330 8. Normative References 332 [I-D.ietf-bier-idr-extensions] 333 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 334 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 335 idr-extensions-06 (work in progress), January 2019. 337 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 338 Topology (MT) Routing in Intermediate System to 339 Intermediate Systems (IS-ISs)", RFC 5120, 340 DOI 10.17487/RFC5120, February 2008, 341 . 343 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 344 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 345 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 346 2015, . 348 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 349 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 350 Explicit Replication (BIER)", RFC 8279, 351 DOI 10.17487/RFC8279, November 2017, 352 . 354 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 355 Zhang, "Bit Index Explicit Replication (BIER) Support via 356 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 357 . 359 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 360 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 361 Extensions for Bit Index Explicit Replication (BIER)", 362 RFC 8444, DOI 10.17487/RFC8444, November 2018, 363 . 365 Authors' Addresses 367 Zheng(Sandy) Zhang 368 ZTE Corporation 370 EMail: zzhang_ietf@hotmail.com 372 Bo Wu 373 ZTE Corporation 375 EMail: w1973941761@163.com 377 Zhaohui Zhang 378 Juniper Networks 380 EMail: zzhang@juniper.net 382 IJsbrand Wijnands 383 Cisco Systems, Inc. 385 EMail: ice@cisco.com