idnits 2.17.1 draft-venaas-bier-mtud-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2241 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-bier-isis-extensions-09 == Outdated reference: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-15 == Outdated reference: A later version (-16) exists of draft-ietf-bier-path-mtu-discovery-03 Summary: 1 error (**), 0 flaws (~~), 4 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 M. Sivakumar 4 Intended status: Experimental IJ. Wijnands 5 Expires: September 6, 2018 L. Ginsberg 6 Cisco Systems, Inc. 7 March 5, 2018 9 BIER MTU Discovery 10 draft-venaas-bier-mtud-00 12 Abstract 14 This document defines an IGP based mechanism for discovering the MTU 15 of a BIER sub-domain. This document defines extensions to OSPF and 16 IS-IS, but other protocols could potentially be extended. MTU 17 discovery is usually done for a given path, while this document 18 defines it for a sub-domain. This allows the computed MTU to be 19 independent of the set of receivers. Also, the MTU is independent of 20 rerouting events within the sub-domain. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 3. IS-IS BIER MTU Sub-sub-TLV . . . . . . . . . . . . . . . . . 3 59 4. OSPF BIER MTU Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 60 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 6.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 This document defines an IGP based mechanism for discovering the MTU 69 of a BIER sub-domain. The discovered MTU indicates the largest 70 possible BIER payload, such as an IP packet, that can be sent across 71 any link in a BIER sub-domain. This is different from 72 [I-D.ietf-bier-path-mtu-discovery] which performs Path MTU Discovery 73 (PMTUD) for a set of receivers. PMTUD is based on probing, and when 74 there are routing changes, e.g., a link going down, the actual MTU 75 for a path may become less than was previously discovered, and there 76 will be some delay until the next probe is performed. Also, the set 77 of receivers for a flow may change at any time, which may cause the 78 MTU to change. This document instead discovers a BIER sub-domain 79 MTU, which is independent of paths and receivers within the sub- 80 domain. 82 For convenience we will refer to an interface on a router as a BIER 83 interface if the router has a BIER neighbor on the interface. That 84 is, there is a directly connected router on that interface that is 85 announcing a BIER prefix. We say that it is a BIER interface in a 86 given sub-domain if the router itself announces a prefix tagged with 87 the sub-domain, and there is BIER neighbor on the interface also 88 announcing a prefix tagged with the sub-domain. 90 In order to allow MTU discovery in a BIER sub-domain, the procedure 91 is as follows. Every BIER router, for each sub-domain with at least 92 one local BIER interface in the sub-domain, per the above definition 93 of a BIER interface, determines the largest payload that can be sent 94 BIER encapsulated out of any of its BIER interfaces in the sub- 95 domain. That is, for each local BIER interface in the sub-domain, it 96 needs to determine the size of the largest BIER encapsulated payload 97 that can be sent out of that interface. We define the local sub- 98 domain MTU of a router to be the minimum of the per BIER interface 99 maximum payload size. 101 A BIER router announces a BIER prefix in either IS-IS or OSPF as 102 specified in [I-D.ietf-bier-isis-extensions] and 103 [I-D.ietf-bier-ospf-bier-extensions]. They both define a BIER Sub- 104 TLV to be included with the prefix. There is one BIER Sub-TLV 105 included for each sub-domain. This document defines how a router 106 includes its local sub-domain MTU in each of the BIER Sub-TLVs it 107 advertizes. 109 A router can discover the MTU of a BIER sub-domain by identifying all 110 the prefixes that have a BIER Sub-TLV for the sub-domain. It then 111 computes the minimum of the advertised MTU values for that sub- 112 domain. This includes its local sub-domain MTU. This allows all the 113 routers in the sub-domain to discover the same sub-domain wide MTU. 115 Note that a router should announce a new local MTU for a sub-domain 116 immediately if the value becomes smaller than what it currently 117 announces. This would happen if the MTU of an interface is 118 configured to a smaller value, or the first BIER neighbor for a sub- 119 domain is detected on an interface, and the MTU of the interface is 120 less than all the other local BIER interfaces in the sub-domain. 121 However, if BIER neighbors go away, or if an interface goes down, so 122 that the local MTU becomes larger, a router SHOULD NOT immediately 123 announce the larger value. A router MAY after some delay announce 124 the new larger MTU. The intention is that dynamic events such as a 125 quick link flap should not cause the announced MTU to be increased. 127 2. Conventions used in this document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 3. IS-IS BIER MTU Sub-sub-TLV 137 A router uses the BIER MTU Sub-sub-TLV to announce the minimum BIER 138 MTU of all its BIER enabled interfaces. The Sub-sub-TLV MUST be 139 ignored if it is included multiple times. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Type | Length | MTU | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Type: TBD 149 Length: 2 151 MTU: MTU in octets 153 4. OSPF BIER MTU Sub-TLV 155 A router uses the BIER MTU Sub-TLV to annonce the minimum BIER MTU of 156 all its BIER enabled interfaces. It is a Sub-TLV of the BIER Sub- 157 TLV, and SHOULD be included exactly once within each of the 158 advertised BIER Sub-TLVs. The Sub-TLV MUST be ignored if it is 159 included multiple times. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | MTU | Reserved | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Type: TBD2 171 Length: 4 173 MTU: MTU in octets 175 5. IANA considerations 177 An allocation from the "sub-sub-TLVs for BIER Info sub-TLV" registry 178 as defined in [I-D.ietf-bier-isis-extensions] is requested for the 179 IS-IS BIER MTU Sub-sub-TLV. Please replace the string TBD in this 180 document with the appropriate value. 182 An allocation from the "OSPF Extended Prefix sub-TLV" registry as 183 defined in [RFC7684] is requested for the OSPF BIER MTU Sub-TLV. 184 Please replace the string TBD2 in this document with the appropriate 185 value. 187 6. References 189 6.1. Normative References 191 [I-D.ietf-bier-isis-extensions] 192 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 193 "BIER support via ISIS", draft-ietf-bier-isis- 194 extensions-09 (work in progress), February 2018. 196 [I-D.ietf-bier-ospf-bier-extensions] 197 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 198 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 199 for BIER", draft-ietf-bier-ospf-bier-extensions-15 (work 200 in progress), February 2018. 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, 204 DOI 10.17487/RFC2119, March 1997, 205 . 207 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 208 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 209 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 210 2015, . 212 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 213 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 214 May 2017, . 216 6.2. Informative References 218 [I-D.ietf-bier-path-mtu-discovery] 219 Mirsky, G., Przygienda, T., and A. Dolganow, "Path Maximum 220 Transmission Unit Discovery (PMTUD) for Bit Index Explicit 221 Replication (BIER) Layer", draft-ietf-bier-path-mtu- 222 discovery-03 (work in progress), January 2018. 224 Authors' Addresses 226 Stig Venaas 227 Cisco Systems, Inc. 228 Tasman Drive 229 San Jose CA 95134 230 USA 232 Email: stig@cisco.com 233 Mahesh Sivakumar 234 Cisco Systems, Inc. 235 Tasman Drive 236 San Jose CA 95134 237 USA 239 Email: masivaku@cisco.com 241 IJsbrand Wijnands 242 Cisco Systems, Inc. 243 De kleetlaan 6a 244 Diegem 1831 245 Belgium 247 Email: ice@cisco.com 249 Les Ginsberg 250 Cisco Systems, Inc. 251 Tasman Drive 252 San Jose CA 95134 253 USA 255 Email: ginsberg@cisco.com