idnits 2.17.1 draft-venaas-bier-mtud-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 a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2018) is 2011 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-bier-path-mtu-discovery-04 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft IJ. Wijnands 4 Intended status: Experimental L. Ginsberg 5 Expires: April 19, 2019 Cisco Systems, Inc. 6 M. Sivakumar 7 Juniper Networks 8 October 16, 2018 10 BIER MTU Discovery 11 draft-venaas-bier-mtud-02 13 Abstract 15 This document defines an IGP based mechanism for discovering the MTU 16 of a BIER sub-domain. This document defines extensions to OSPF and 17 IS-IS, but other protocols could potentially be extended. MTU 18 discovery is usually done for a given path, while this document 19 defines it for a sub-domain. This allows the computed MTU to be 20 independent of the set of receivers. Also, the MTU is independent of 21 rerouting events within the sub-domain. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 19, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. MTU discovery procedure . . . . . . . . . . . . . . . . . . . 3 60 4. IS-IS BIER Sub-Domain MTU Sub-sub-TLV . . . . . . . . . . . . 4 61 5. OSPF BIER Sub-Domain MTU Sub-TLV . . . . . . . . . . . . . . 5 62 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 8.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 This document defines an IGP based mechanism for discovering the MTU 72 of a BIER sub-domain. The discovered MTU indicates the largest 73 possible BIER packet that can be sent across any link in a BIER sub- 74 domain. This is different from [I-D.ietf-bier-path-mtu-discovery] 75 which performs Path MTU Discovery (PMTUD) for a set of receivers. 76 PMTUD is based on probing, and when there are routing changes, e.g., 77 a link going down, the actual MTU for a path may become less than was 78 previously discovered, and there will be some delay until the next 79 probe is performed. Also, the set of receivers for a flow may change 80 at any time, which may cause the MTU to change. This document 81 instead discovers a BIER sub-domain MTU, which is independent of 82 paths and receivers within the sub-domain. 84 Discovering the sub-domain MTU is much simpler than discovering the 85 multicast path MTU, and is more robust with regards to path changes 86 as discussed above. However, the sub-domain MTU may be a lot smaller 87 than the path MTU would have been for a given flow. The discovery 88 mechanisms may be combined, allowing the discovery of the path MTU 89 for certain flows as needed. 91 The BIER sub-domain MTU defined here provides the maximum size of a 92 BIER packet that can be forwarded through the sub-domain regardless 93 of path. A BIER router that performs BIER encapsulation will need to 94 subtract the encapsulation overhead to find the largest size packet 95 that can be encapsulated. This would give the IP MTU, and may be 96 used for IP PMTUD by for instance sending an ICMP Packet too big 97 message if an IP packet will be too large after BIER encapsulation. 99 2. Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. MTU discovery procedure 109 An interface on a router is said to be a BIER interface if the router 110 has a BIER neighbor on the interface. That is, there is a directly 111 connected router on that interface that is announcing a BIER prefix. 112 Further, the BIER interface is said to belong to a given sub-domain 113 if the router itself announces a prefix tagged with the sub-domain, 114 and there is BIER neighbor on the interface also announcing a prefix 115 tagged with the sub-domain. 117 The BIER MTU of an interface is the largest BIER packet that can be 118 sent out of the interface. Further, the local sub-domain MTU of a 119 router is the minimum of all the BIER MTUs of the BIER interfaces in 120 the sub-domain. Note that the local sub-domain MTU of a router is 121 only defined if it has at least one BIER interface in the sub-domain. 123 A BIER router announces a BIER prefix in either IS-IS or OSPF as 124 specified in [RFC8401] and [I-D.ietf-bier-ospf-bier-extensions]. 125 They both define a BIER Sub-TLV to be included with the prefix. 126 There is one BIER Sub-TLV included for each sub-domain. This 127 document defines how a router includes its local sub-domain MTU in 128 each of the BIER Sub-TLVs it advertizes. 130 A router can discover the MTU of a BIER sub-domain by identifying all 131 the prefixes that have a BIER Sub-TLV for the sub-domain. It then 132 computes the minimum of the advertised MTU values for that sub- 133 domain. This includes its own local sub-domain MTU. This allows all 134 the routers in the sub-domain to discover the same sub-domain wide 135 MTU. 137 Note that a router should announce a new local MTU for a sub-domain 138 immediately if the value becomes smaller than what it currently 139 announces. This would happen if the MTU of an interface is 140 configured to a smaller value, or the first BIER neighbor for a sub- 141 domain is detected on an interface, and the MTU of the interface is 142 less than all the other local BIER interfaces in the sub-domain. 143 However, if BIER neighbors go away, or if an interface goes down, so 144 that the local MTU becomes larger, a router SHOULD NOT immediately 145 announce the larger value. A router MAY after some delay announce 146 the new larger MTU. The intention is that dynamic events such as a 147 quick link flap should not cause the announced MTU to be increased. 149 It is a concern that the sub-domain MTU will be based on the link 150 with the smallest MTU. This means that if for instance a single link 151 is accidentally configured with an extra small MTU, it will impact 152 the sub-domain MTU and potentially all the flows through the sub- 153 domain. As an example, an administrator might decide to use jumbo 154 frames and has configured that on all the links. But accidentally 155 forget to configure it on a new link before it is brought up. To 156 provide some protection against this, an implementation SHOULD 157 provide a configurable minimum BIER sub-domain MTU. When this is 158 configured, the MTU discovery is still done according to the above 159 procedure, but if the resulting MTU value is less than the configured 160 minimum, the configured minimum MUST be used instead. If the 161 discovery procedure later should provide an MTU larger than the 162 minimum, then the discovered MTU MUST be used. An implementation 163 SHOULD provide notification to the administrator when the discovered 164 MTU is less than the minimum, as this is likely a configuration 165 mistake that should be corrected. 167 4. IS-IS BIER Sub-Domain MTU Sub-sub-TLV 169 A router uses the BIER Sub-Domain MTU Sub-sub-TLV to announce the 170 minimum BIER MTU of all its BIER enabled interfaces in a sub-domain. 171 The BIER Sub-Domain MTU is the largest BIER packet that can be sent 172 out of all the interfaces in a sub-domain. The Sub-sub-TLV MUST be 173 ignored if it is included multiple times. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type | Length | MTU | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Type: TBD 183 Length: 2 185 MTU: MTU in octets 187 5. OSPF BIER Sub-Domain MTU Sub-TLV 189 A router uses the BIER Sub-Domain MTU Sub-TLV to announce the minimum 190 BIER MTU of all its BIER enabled interfaces in a sub-domain. The 191 BIER Sub-Domain MTU is the largest BIER packet that can be sent out 192 of all the interfaces in a sub-domain. The Sub-TLV MUST be ignored 193 if it is included multiple times. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type | Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | MTU | Reserved | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Type: TBD2 205 Length: 4 207 MTU: MTU in octets 209 6. IANA considerations 211 An allocation from the "sub-sub-TLVs for BIER Info sub-TLV" registry 212 as defined in [RFC8401] is requested for the IS-IS BIER Sub-Domain 213 MTU Sub-sub-TLV. Please replace the string TBD in this document with 214 the appropriate value. 216 An allocation from the "OSPF Extended Prefix sub-TLV" registry as 217 defined in [RFC7684] is requested for the OSPF BIER Sub-Domain MTU 218 Sub-TLV. Please replace the string TBD2 in this document with the 219 appropriate value. 221 7. Acknowledgments 223 The authors would like to thank Greg Mirsky in particular for 224 fruitful discussions and input. Valuable comments were also provided 225 by Alia Atlas, Eric C Rosen, Toerless Eckert, Tony Przygienda and Xie 226 Jingrong. 228 8. References 229 8.1. Normative References 231 [I-D.ietf-bier-ospf-bier-extensions] 232 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 233 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2 234 Extensions for BIER", draft-ietf-bier-ospf-bier- 235 extensions-18 (work in progress), June 2018. 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, 239 DOI 10.17487/RFC2119, March 1997, 240 . 242 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 243 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 244 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 245 2015, . 247 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 248 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 249 May 2017, . 251 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 252 Zhang, "Bit Index Explicit Replication (BIER) Support via 253 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 254 . 256 8.2. Informative References 258 [I-D.ietf-bier-path-mtu-discovery] 259 Mirsky, G., Przygienda, T., and A. Dolganow, "Path Maximum 260 Transmission Unit Discovery (PMTUD) for Bit Index Explicit 261 Replication (BIER) Layer", draft-ietf-bier-path-mtu- 262 discovery-04 (work in progress), June 2018. 264 Authors' Addresses 266 Stig Venaas 267 Cisco Systems, Inc. 268 Tasman Drive 269 San Jose CA 95134 270 USA 272 Email: stig@cisco.com 273 IJsbrand Wijnands 274 Cisco Systems, Inc. 275 De kleetlaan 6a 276 Diegem 1831 277 Belgium 279 Email: ice@cisco.com 281 Les Ginsberg 282 Cisco Systems, Inc. 283 Tasman Drive 284 San Jose CA 95134 285 USA 287 Email: ginsberg@cisco.com 289 Mahesh Sivakumar 290 Juniper Networks 291 1133 Innovation Way 292 Sunnyvale CA 94089 293 USA 295 Email: sivakumar.mahesh@gmail.com