idnits 2.17.00 (12 Aug 2021) /tmp/idnits57679/draft-zzhang-bier-rift-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 3 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 224 has weird spacing: '...nIdType sub...' == Line 232 has weird spacing: '...nIdType sub...' == Line 245 has weird spacing: '...IdRange proxy...' -- The document date (March 5, 2018) is 1531 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 263, but no explicit reference was found in the text == Outdated reference: draft-ietf-bier-isis-extensions has been published as RFC 8401 == Outdated reference: draft-ietf-bier-ospf-bier-extensions has been published as RFC 8444 == Outdated reference: A later version (-07) exists of draft-zwzw-bier-prefix-redistribute-00 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Zhaohui. Zhang 3 Internet-Draft Shaowen. Ma 4 Intended status: Standards Track Juniper Networks 5 Expires: September 6, 2018 Zheng. Zhang 6 ZTE Corporation 7 March 5, 2018 9 Supporting BIER with RIFT 10 draft-zzhang-bier-rift-00 12 Abstract 14 This document specifies extensions to RIFT protocol to support BIER. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC2119. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 6, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Advertising BIER Information For non-MPLS Encapsulation . . . 3 59 4. Advertising BIER Information Northbound . . . . . . . . . . . 4 60 5. Advertising BIER Information Southbound . . . . . . . . . . . 4 61 5.1. Local BIER Information . . . . . . . . . . . . . . . . . 4 62 5.2. Proxied BFR-ID Ranges . . . . . . . . . . . . . . . . . . 4 63 6. Information Elements Schema . . . . . . . . . . . . . . . . . 5 64 6.1. bier.thrift . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.2. Additions to encoding.thrift . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 9.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Terminologies 75 Familiarity with BIER and RIFT protocols and procedures is assumed. 76 Some terminologies are listed below for convenience. 78 [To be added.] 80 2. Introduction 82 BIER [RFC8279] ... (to be expanded) 84 RIFT [I-D.przygienda-rift] is a new protocol specifically designed 85 for CLOS and fat-tree network topologies. As a hybrid between Link 86 State Routing and Distance Vector Routing, it does LSR in northbound 87 (towards the spine) and DVR in southbound (towards the leaves). 89 [I-D.ietf-bier-isis-extensions] and 90 [I-D.ietf-bier-ospf-bier-extensions] specify ISIS/OSPF extensions to 91 support BIER in an ISIS/OSPF domain. The same approach applies to 92 RIFT in the northbound LSR. 94 [I-D.zwzw-bier-prefix-redistribute] specifies methods to advertise 95 BIER information via default or summary/aggregate routes advertised 96 from one IGP area/domain to another. Similar approach applies to 97 RIFT in the southbound DVR. 99 BIER encapsulation, whether it is based on MPLS or not, is covered in 100 [RFC8296]. However, the OSPF/ISIS extensions for BIER only covers 101 signaling needed for MPLS encapsulation. RIFT is targeted at DC 102 deployments, where MPLS may not be used. This document covers 103 signaling for both BIER MPLS and non-MPLS encapsulation with RIFT. 105 The details are provided in following sections. 107 3. Advertising BIER Information For non-MPLS Encapsulation 109 In the BIER architecture, a BIER sub-domain may have multiple 110 BitStringLengths (BSLs) and multiple Encapsulations (Encaps). A 111 single multicast packet coming from outside the BIER sub-domain may 112 be sent as multiple BIER packets, one for each set that is identified 113 by a SetID (SI). An incoming BIER packet is forwarded according to a 114 BIFT for the tuple. Each BIFT is identified by a 115 20-bit opaque number (BIFT-ID) in the packet. 117 With MPLS encapsulation, the BIFT-ID for an incoming BIER packet is 118 simply an MPLS label allocated by the receiving BFR for the BIFT. 119 For each tuple, OSPF/ISIS advertises a block of contiguous 120 labels, one label for each SI needed for the tuple, in the MPLS 121 Encapsulation sub-sub-TLV as part of the BIER sub-TLV, which is 122 attached to the Extended Reachability TLV (ISIS case) or the Extended 123 Prefix TLV (OSPF case) for the BFR's BIER Prefix. 125 With non-MPLS encapsulation, the BIFT-ID in the packet is at the same 126 position as the label in MPLS encapsulation case. Its semantics is 127 no different from the MPLS case in that as an 20-bit opaque value, it 128 leads to the BIFT according to which the BIER packet is forwarded. 129 Beyond the semantics, there are two differences from the MPLS case 130 though: 132 o MPLS infrastructure is not needed. 134 o While each BFR could allocate local BIFT-IDs independently and 135 advertise them just like in MPLS case, for the same 136 tuple all BFRs could optionally auto-derive or 137 be provisioned with the same BIFT-ID and no signaling is needed in 138 that case. 140 One may consider that if MPLS would allow to use consistently 141 provisioned BIER labels on all BFRs, then the second difference 142 listed above does not exist anymore. 144 In this specification, if locally significant BIFT-IDs are to be used 145 with non-MPLS encapsulation, the BIFT-IDs are advertised the same way 146 as in the MPLS case - by a BIFT-ID block, which is a block of 147 contiguous labels in MPLS case or a block of contiguous opaque 20-bit 148 values in non-MPLS case. The only difference is the type of 149 encapsulation. 151 If consistently provisioned or auto-derived BIFT-IDs are used with 152 non-MPLS encapsulation, then no BIFT-ID block is signaled. Just the 153 encapsulation type is signaled. 155 4. Advertising BIER Information Northbound 157 Nothing special here compared to OSPF/ISIS. A node's local BIER 158 information as described in the previous section is attached to a 159 local BIER Prefix. Details to be added. 161 5. Advertising BIER Information Southbound 163 5.1. Local BIER Information 165 Similar to the northbound case, a node's local BIER information is 166 attached to a local BIER prefix that is advertised southbound. 168 5.2. Proxied BFR-ID Ranges 170 On the southbound, a node advertises a default route, plus certain 171 prefixes to prevent blackholing or suboptimal routing upon link 172 failures. Those prefixes and default route are like the summary 173 routes and default route in [I-D.zwzw-bier-prefix-redistribute], and 174 similarly they carry BFR-IDs corresponding to the covered BIER 175 Prefixes. 177 Consider a RIFT network with a BIER sub-domain of 200 BFIR/BFERs. 178 Each non-leaf node is provisioned that BFR-ID 1-200 are used. 179 Suppose a node X advertise southbound a default route RT1 and 180 disaggregation routes RT2/RT3. RT2 and RT3 MUST advertise BFR-IDs 181 covered by them (e.g. BFR-ID 100/102/150 covered by RT2 and BFR-ID 182 101/103 covered by RT3), while the default route RT1 can always 183 advertise that all BFR-ID 1~200 are covered by it and does not need 184 to exclude BFR-ID 100/102/150 and 101/103 that are covered by RT2/ 185 RT3. When a southern node receives RT1 and RT2/RT3, it installs BFR- 186 ID 100/102/150 in its BIFT according to RT2, 101/103 in its BIFT 187 according to RT3, and installs other BFR-IDs (or just a default 188 route) in its BIFT according to RT1. 190 6. Information Elements Schema 192 This document introduces a bier.thrif schema with definitions to be 193 used in RIFT encoding.thrift. 195 6.1. bier.thrift 197 typedef i8 SubdomainIdType 198 typedef i16 BfrIdType 199 typedef i8 BARType 200 typedef i8 IPAType 201 typedef i16 BSLType /* Number of bits */ 202 typedef i32 BiftIdType /* Only the most significant 20 bits are used */ 204 enum EncapsulationType { 205 mpls = 0; 206 non-mpls = 1; 207 } 209 /* Similar to the label range in OSPF/ISIS extensions for BIER */ 210 struct BiftIdBlock { 211 1: required BiftIdType bift_id_base; 212 2. required i8 bift_id_range; 213 } 215 /* Similar to the MPLS Encapsulation sub-sub-TLV in OSPF/ISIS */ 216 struct EncapStruct { 217 1: required EncapsulationType encap_type; 218 2: required BSLType bsl; 219 3: optional BiftIdBlock bift_id_block; 220 } 222 /*BIER node information. Similar to BIER sub-TLV in OSPF/ISIS. */ 223 struct BierInfo { 224 1: required SubdomainIdType subdomain_id; 225 2: required BfrIdType bfr_id; 226 3: required BARType bar; 227 4: required IPAType ipa; 228 5. required EncapStruct encaps; /* one or more */ 229 } 231 struct ProxyBfrIdRange { 232 1: required SubdomainIdType subdomain_id; 233 2: required BfrIdType bfr_id_base; 234 3: required BSLType bfr_id_range; 235 } 237 6.2. Additions to encoding.thrift 239 The PrefixAttributes in encoding.rift now has two optional elements: 241 struct PrefixAttributes { 242 ... 243 2: optional BierInfo bier_info; /* BIER info for a 244 * local BIER Prefix */ 245 3. optional ProxyBfrIdRange proxy_bfr_id; /* one or more proxy 246 * BFR-ID ranges covered 247 * by this prefix */ 248 } 250 7. IANA Considerations 252 8. Acknowledgements 254 9. References 256 9.1. Normative References 258 [I-D.przygienda-rift] 259 Przygienda, T., Sharma, A., Atlas, A., and J. Drake, 260 "RIFT: Routing in Fat Trees", draft-przygienda-rift-05 261 (work in progress), March 2018. 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 269 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 270 Explicit Replication (BIER)", RFC 8279, 271 DOI 10.17487/RFC8279, November 2017, 272 . 274 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 275 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 276 for Bit Index Explicit Replication (BIER) in MPLS and Non- 277 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 278 2018, . 280 9.2. Informative References 282 [I-D.ietf-bier-isis-extensions] 283 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 284 "BIER support via ISIS", draft-ietf-bier-isis- 285 extensions-09 (work in progress), February 2018. 287 [I-D.ietf-bier-ospf-bier-extensions] 288 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 289 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 290 for BIER", draft-ietf-bier-ospf-bier-extensions-15 (work 291 in progress), February 2018. 293 [I-D.zwzw-bier-prefix-redistribute] 294 Zhang, Z., Bo, W., Zhang, Z., and I. Wijnands, "BIER 295 Prefix Redistribute", draft-zwzw-bier-prefix- 296 redistribute-00 (work in progress), January 2018. 298 Authors' Addresses 300 Zhaohui Zhang 301 Juniper Networks 303 EMail: zzhang@juniper.net 305 Shaowen Ma 306 Juniper Networks 308 EMail: mashao@juniper.net 310 Zheng Zhang 311 ZTE Corporation 313 EMail: zhang.zheng@zte.com.cn