idnits 2.17.1 draft-zzhang-bier-tether-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: BFRx MUST not send BIER packets natively to X even if X advertises BIER information. BFRx knows that X does not really support BIER either from provisioning or from the BIER Helper Node sub-sub-TLV advertised by X. -- The document date (January 30, 2019) is 1910 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) == Unused Reference: 'RFC2119' is defined on line 262, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-bier-idr-extensions-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track N. Warnke 5 Expires: August 3, 2019 Deutsche Telekom 6 I. Wijnands 7 Cisco Systems 8 January 30, 2019 10 Tethering A BIER Router To A BIER-incapable Router 11 draft-zzhang-bier-tether-01 13 Abstract 15 This document specifies optional procedures to optimize the handling 16 of Bit Index Explicit Replication (BIER) incapable routers, by 17 tethering a BIER router to a BIER incapable router. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC2119. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 3, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Advertising from Helped Node . . . . . . . . . . . . . . 4 63 3.2. Advertising from Helper Node . . . . . . . . . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Terminologies 72 Familiarity with BIER architecture, protocols and procedures is 73 assumed. Some terminologies are listed below for convenience. 75 [To be added]. 77 2. Introduction 79 Consider the following scenario where router X does not support BIER. 81 ------ BFR2 ------- BFER2 82 / 83 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 84 ......... 85 \ 86 ------ BFRn ------- BFERn 88 For BFR1 to forward BIER traffic towards BFR2...BFRn, it needs to 89 tunnel individual copies through X. This degrades to "ingress" 90 replication to those BFRs. If X's connections to BFRs are long 91 distance or bandwidth limited, and n is large, it becomes very 92 inefficient. 94 A solution to the inefficient tunneling from BFRs is to tether a BFRx 95 to X: 97 ------ BFR2 ------- BFER2 98 / 99 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 100 / \ ......... 101 / \ 102 BFRx ------ BFRn ------- BFERn 104 Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will get 105 BIER packets to BFRx, who will then tunnel to BFR2, ..., BFRn. There 106 could be fat and local pipes between the tethered BFRx and X, so 107 ingress replication from BFRx is acceptable. 109 For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to 110 be announced in IGP as a forwarding adjacency so that BFRx will 111 appear on the SPF tree. This need to happen in a BIER specific 112 topology so that unicast traffic would not be tunneled to BFRx. 113 Obviously this is operationally cumbersome. 115 Section 6.9 of BIER architecture specification [RFC8279] describes a 116 method that tunnels BIER packets through incapable routers without 117 the need to announce tunnels. However that does not work here, 118 because BFRx will not appear on the SPF tree of BFR1. 120 There is a simple solution to the problem though. Even though X does 121 not support BIER forwarding, it could advertises BIER information as 122 if it supported BIER so BFRs will send BIER packets to it. The BIER 123 packets have a BIER label in front of the BIER header and X will use 124 the BIER label to label switch to BFRx, who will in turn do BIER 125 forwarding to other BFRs but via tunneling as described in section 126 6.9 of BIER architecture spec. 128 Even though X advertises as if it supported BIER, BFRx needs to know 129 that X does not really support BIER so it will tunnel to other BFRs 130 through X. The knowledge is through static provisioning or through 131 additional signaling. In the latter case, X could advertise that 132 BFRx is its helper node, so that other BFRs could optionally use the 133 Section 6.9 method to tunnel to BFRx, instead of sending native BIER 134 packets to X and rely on X label switching to BFRx. This also allows 135 it to work in the non-MPLS case. 137 Alternatively, instead of for X to advertise that it supports BIER 138 but relies on helper BFRx, BFRx could advertise that it is X's helper 139 and other BFRs will use BFRx (instead of X's children on the SPF 140 tree) to replace X during its post-SPF processing as described in 141 section 6.9 of BIER architecture spec. That way, X does not need any 142 special knowledge, provisioning or procedure. 144 The two options both have pros and cons - the first option only needs 145 X and BFRx to support the new procedure while the second option does 146 not require anything to be done to the BIER incapable X. 148 BFRx could also be connected to other routers in the network so that 149 it could send BIER packets through other routers as well, not 150 necessarily tunneling through X. To prevent routing loops, smallest 151 metric, which is 1, must be announced for links between X and BFRx in 152 both directions. 154 While the example shows a local connection between BFRx and X, it 155 does not have to be like that. As long as packets can arrive at BFRx 156 without requiring X to do BIER forwarding, it should work. For 157 example, X could label switch incoming BIER packets through a tunnel 158 to BFRx, or other BFRs could tunnel BIER packets to BFRx based on X's 159 advertisement that BFRx is its helper. This does require a BIER 160 specific topology in which the BFRx-X tunnel is announced with the 161 smallest metric 1. 163 3. Specification 165 The procedures in this document apply when a BFRx is tethered to a 166 BIER incapable router X as X's helper for BIER forwarding. 168 BFRx MUST not send BIER packets natively to X even if X advertises 169 BIER information. BFRx knows that X does not really support BIER 170 either from provisioning or from the BIER Helper Node sub-sub-TLV 171 advertised by X. 173 Either of the following two methods may be used for ISIS [RFC8401] 174 and OSPF [I-D.ietf-bier-ospf-bier-extensions]. 176 A future revision will specify the extensions when BGP is used as the 177 BIER signaling protocol [I-D.ietf-bier-idr-extensions]. 179 3.1. Advertising from Helped Node 181 For non-MPLS encapsulation, X MUST advertise a BIER Helper Node sub- 182 sub-TLV that specifies the BIER prefix of the helper BFRx. Other 183 BFRs MUST use the Section 6.9 procedure modified as following: X is 184 treated as BIER incapable (because of the BIER Helper Node sub-sub- 185 TLV), and is replaced with the BFRx (instead of X's children on the 186 SPF tree) during the post-SPF processing. 188 This requires other BFRs to recognize the BIER Helper Node sub-sub- 189 TLV. The same procedure MAY be used For MPLS encapsulation, though 190 with the following alternative for MPLS encapsulation, tethering is 191 transparent to other BFRs (except the helper node BFRx) - they do not 192 need to be aware that X does not support BIER at all. 194 For MPLS encapsulation, X MAY advertises BIER information as if it 195 supported BIER forwarding, including the MPLS Encapsulation sub-sub- 196 TLV with a label range. X MUST set up its forwarding state such that 197 incoming packets with a BIER label in its advertised label range are 198 label switched to BFRx, either over a direct link or through a 199 tunnel. The incoming label is swapped to a BIER label advertised by 200 BFRx for the that the incoming label 201 corresponds to. 203 Notice that both methods can be used for MPLS encapsulation at the 204 same time. In that case another BFR may send BIER packets to X 205 natively, or tunnel to BFRx directly. 207 3.2. Advertising from Helper Node 209 With this method, the helper node (BFRx) MUST advertise a BIER Helped 210 Node sub-sub-TLV that specifies the BIER incapable node (X) that this 211 node helps. When other BFRs follow the post-SPF processing 212 procedures as specified in section 6.9 of the BIER architecture spec 213 [RFC8279], they replace the helped node on the SPF tree with the 214 helper node (instead of the children of the helped node). 216 4. Security Considerations 218 This specification does not introduce additional security concerns 219 beyond those already discussed in BIER architecture and OSPF/ISIS/BGP 220 extensions for BIER signaling. 222 5. IANA Considerations 224 This document requests two new sub-sub-TLV type values from the "Sub- 225 sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV 226 Codepoints" registry: 228 Type Name 229 ---- ---- 230 TBD1 BIER Helper Node 231 TBD2 BIER Helped Node 233 This document also requests two new sub-TLV type values from the 234 OSPFv2 Extended Prefix TLV Sub-TLV registry: 236 Type Name 237 ---- ---- 238 TBD3 BIER Helper Node 239 TBD4 BIER Helped Node 241 All have the same format: the value is BIER prefix of the helper/ 242 helped node and the length is 4 for IPv4 and 16 for IPv6. 244 6. Acknowledgements 246 The author wants to thank Eric Rosen and Antonie Przygienda for their 247 review, comments and suggestions. 249 7. Normative References 251 [I-D.ietf-bier-idr-extensions] 252 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 253 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 254 idr-extensions-06 (work in progress), January 2019. 256 [I-D.ietf-bier-ospf-bier-extensions] 257 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 258 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2 259 Extensions for BIER", draft-ietf-bier-ospf-bier- 260 extensions-18 (work in progress), June 2018. 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, 264 DOI 10.17487/RFC2119, March 1997, 265 . 267 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 268 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 269 Explicit Replication (BIER)", RFC 8279, 270 DOI 10.17487/RFC8279, November 2017, 271 . 273 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 274 Zhang, "Bit Index Explicit Replication (BIER) Support via 275 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 276 . 278 Authors' Addresses 280 Zhaohui Zhang 281 Juniper Networks 283 EMail: zzhang@juniper.net 284 Nils Warnke 285 Deutsche Telekom 287 EMail: Nils.Warnke@telekom.de 289 IJsbrand Wijnands 290 Cisco Systems 292 EMail: ice@cisco.com