idnits 2.17.1 draft-venaas-bier-mtud-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 : ---------------------------------------------------------------------------- ** 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 (June 28, 2018) is 2121 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: December 30, 2018 Cisco Systems, Inc. 6 M. Sivakumar 7 Juniper Networks 8 June 28, 2018 10 BIER MTU Discovery 11 draft-venaas-bier-mtud-01 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 December 30, 2018. 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 . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . 4 62 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 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 payload, such as an IP packet, that can be sent across 74 any link in a BIER sub-domain. This is different from 75 [I-D.ietf-bier-path-mtu-discovery] which performs Path MTU Discovery 76 (PMTUD) for a set of receivers. PMTUD is based on probing, and when 77 there are routing changes, e.g., a link going down, the actual MTU 78 for a path may become less than was previously discovered, and there 79 will be some delay until the next probe is performed. Also, the set 80 of receivers for a flow may change at any time, which may cause the 81 MTU to change. This document instead discovers a BIER sub-domain 82 MTU, which is independent of paths and receivers within the sub- 83 domain. 85 Discovering the sub-domain MTU is much simpler than discovering the 86 multicast path MTU, and is more robust with regards to path changes 87 as discussed above. However, the sub-domain MTU may be a lot smaller 88 than the path MTU would have been for a given flow. The discovery 89 mechanisms may be combined, allowing the discovery of the path MTU 90 for certain flows as needed. 92 2. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 3. MTU discovery procedure 102 An interface on a router is said to be a BIER interface if the router 103 has a BIER neighbor on the interface. That is, there is a directly 104 connected router on that interface that is announcing a BIER prefix. 105 Further, the BIER interface is said to belong to a given sub-domain 106 if the router itself announces a prefix tagged with the sub-domain, 107 and there is BIER neighbor on the interface also announcing a prefix 108 tagged with the sub-domain. 110 The BIER MTU of an interface is the largest BIER encapsulated payload 111 that can be sent out of the interface. Further, the local sub-domain 112 MTU of a router is the minimum of all the BIER MTUs of the BIER 113 interfaces in the sub-domain. Note that the local sub-domain MTU of 114 a router is only defined if it has at least one BIER interface in the 115 sub-domain. 117 A BIER router announces a BIER prefix in either IS-IS or OSPF as 118 specified in [RFC8401] and [I-D.ietf-bier-ospf-bier-extensions]. 119 They both define a BIER Sub-TLV to be included with the prefix. 120 There is one BIER Sub-TLV included for each sub-domain. This 121 document defines how a router includes its local sub-domain MTU in 122 each of the BIER Sub-TLVs it advertizes. 124 A router can discover the MTU of a BIER sub-domain by identifying all 125 the prefixes that have a BIER Sub-TLV for the sub-domain. It then 126 computes the minimum of the advertised MTU values for that sub- 127 domain. This includes its own local sub-domain MTU. This allows all 128 the routers in the sub-domain to discover the same sub-domain wide 129 MTU. 131 Note that a router should announce a new local MTU for a sub-domain 132 immediately if the value becomes smaller than what it currently 133 announces. This would happen if the MTU of an interface is 134 configured to a smaller value, or the first BIER neighbor for a sub- 135 domain is detected on an interface, and the MTU of the interface is 136 less than all the other local BIER interfaces in the sub-domain. 137 However, if BIER neighbors go away, or if an interface goes down, so 138 that the local MTU becomes larger, a router SHOULD NOT immediately 139 announce the larger value. A router MAY after some delay announce 140 the new larger MTU. The intention is that dynamic events such as a 141 quick link flap should not cause the announced MTU to be increased. 143 4. IS-IS BIER Sub-Domain MTU Sub-sub-TLV 145 A router uses the BIER Sub-Domain MTU Sub-sub-TLV to announce the 146 minimum BIER MTU of all its BIER enabled interfaces in a sub-domain. 147 The BIER Sub-Domain MTU is the largest BIER encapsulated payload that 148 can be sent out of the interfaces in a sub-domain. The Sub-sub-TLV 149 MUST be ignored if it is included multiple times. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type | Length | MTU | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Type: TBD 159 Length: 2 161 MTU: MTU in octets 163 5. OSPF BIER Sub-Domain MTU Sub-TLV 165 A router uses the BIER Sub-Domain MTU Sub-TLV to announce the minimum 166 BIER MTU of all its BIER enabled interfaces in a sub-domain. The 167 BIER Sub-Domain MTU is the largest BIER encapsulated payload that can 168 be sent out of the interfaces in a sub-domain. The Sub-TLV MUST be 169 ignored if it is included multiple times. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type | Length | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | MTU | Reserved | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Type: TBD2 181 Length: 4 183 MTU: MTU in octets 185 6. IANA considerations 187 An allocation from the "sub-sub-TLVs for BIER Info sub-TLV" registry 188 as defined in [RFC8401] is requested for the IS-IS BIER Sub-Domain 189 MTU Sub-sub-TLV. Please replace the string TBD in this document with 190 the appropriate value. 192 An allocation from the "OSPF Extended Prefix sub-TLV" registry as 193 defined in [RFC7684] is requested for the OSPF BIER Sub-Domain MTU 194 Sub-TLV. Please replace the string TBD2 in this document with the 195 appropriate value. 197 7. Acknowledgments 199 The authors would like to thank Greg Mirsky in particular for 200 fruitful discussions and input. Valuable comments were also provided 201 by Toerless Eckert, Tony Przygienda and Xie Jingrong. 203 8. References 205 8.1. Normative References 207 [I-D.ietf-bier-ospf-bier-extensions] 208 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 209 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2 210 Extensions for BIER", draft-ietf-bier-ospf-bier- 211 extensions-18 (work in progress), June 2018. 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, 215 DOI 10.17487/RFC2119, March 1997, 216 . 218 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 219 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 220 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 221 2015, . 223 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 224 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 225 May 2017, . 227 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 228 Zhang, "Bit Index Explicit Replication (BIER) Support via 229 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 230 . 232 8.2. Informative References 234 [I-D.ietf-bier-path-mtu-discovery] 235 Mirsky, G., Przygienda, T., and A. Dolganow, "Path Maximum 236 Transmission Unit Discovery (PMTUD) for Bit Index Explicit 237 Replication (BIER) Layer", draft-ietf-bier-path-mtu- 238 discovery-04 (work in progress), June 2018. 240 Authors' Addresses 242 Stig Venaas 243 Cisco Systems, Inc. 244 Tasman Drive 245 San Jose CA 95134 246 USA 248 Email: stig@cisco.com 250 IJsbrand Wijnands 251 Cisco Systems, Inc. 252 De kleetlaan 6a 253 Diegem 1831 254 Belgium 256 Email: ice@cisco.com 258 Les Ginsberg 259 Cisco Systems, Inc. 260 Tasman Drive 261 San Jose CA 95134 262 USA 264 Email: ginsberg@cisco.com 266 Mahesh Sivakumar 267 Juniper Networks 268 1133 Innovation Way 269 Sunnyvale CA 94089 270 USA 272 Email: sivakumar.mahesh@gmail.com