idnits 2.17.1 draft-ietf-isis-prefix-attributes-04.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 -- The document date (January 4, 2016) is 3036 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track B. Decraene 5 Expires: July 7, 2016 Orange 6 S. Previdi 7 Cisco Systems 8 X. Xu 9 Huawei 10 U. Chunduri 11 Ericsson 12 January 4, 2016 14 IS-IS Prefix Attributes for Extended IP and IPv6 Reachability 15 draft-ietf-isis-prefix-attributes-04.txt 17 Abstract 19 This document introduces new sub-TLVs to support advertisement of IP 20 and IPv6 prefix attribute flags and the source router ID of the 21 router which originated a prefix advertisement. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 7, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. New sub-TLVs for Extended Reachability TLVs . . . . . . . . . 3 65 2.1. IPv4/IPv6 Extended Reachability Attribute Flags . . . . . 3 66 2.2. IPv4/IPv6 Source Router ID . . . . . . . . . . . . . . . 5 67 2.3. Advertising Router IDs . . . . . . . . . . . . . . . . . 5 68 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 6.2. Informational References . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 IS-IS is a link state routing protocol defined in [ISO10589] and 79 [RFC1195]. Extensions in support of advertising new forms of IP/IPv6 80 prefix reachability are defined in [RFC5305], [RFC5308], and 81 [RFC5120]. 83 There are existing use cases in which knowing additional attributes 84 of a prefix is useful. 86 It is useful to know whether an advertised prefix is directly 87 connected to the advertising router or not. In the case of [SR] 88 knowing whether a prefix is directly connected or not determines what 89 action should be taken as regards processing of labels associated 90 with an incoming packet. 92 It is useful to know what addresses can be used as addresses of the 93 node in support of services (e.g., Remote Loop Free Alternate (RLFA) 94 endpoint). 96 Current formats of the Extended Reachability TLVs for both IP and 97 IPv6 are fixed and do not allow the introduction of additional flags 98 without backwards compatibility issues. Therefore a new sub-TLV is 99 introduced which allows for the advertisement of attribute flags 100 associated with prefix advertisements. 102 In cases where multiple node addresses are advertised by a given 103 router it is also useful to be able to associate all of these 104 addresses with a single Router-ID even when prefixes are advertised 105 outside of the area in which they are originated. Therefore a new 106 sub-TLV is introduced to advertise the router-id of the originator of 107 a prefix advertisement. 109 2. New sub-TLVs for Extended Reachability TLVs 111 The following new sub-TLVs are introduced: 113 o IPv4/IPv6 Extended Reachability Attributes 115 o IPv4 Source Router ID 117 o IPv6 Source Router ID 119 All sub-TLVs are applicable to TLVs 135, 235, 236, and/or 237. 121 2.1. IPv4/IPv6 Extended Reachability Attribute Flags 123 This sub-TLV supports the advertisement of additional flags 124 associated with a given prefix advertisement. The behavior of each 125 flag when a prefix advertisement is leaked from one level to another 126 (upwards or downwards) is explicitly defined below. 128 All flags are applicable to TLVs 135, 235, 236, 237 unless otherwise 129 stated. 131 Prefix Attribute Flags 132 Type: 4 (suggested - to be assigned by IANA) 133 Length: Number of octets to follow 134 Value 136 (Length * 8) bits. 138 0 1 2 3 4 5 6 7... 139 +-+-+-+-+-+-+-+-+... 140 |X|R|N| ... 141 +-+-+-+-+-+-+-+-+... 143 Bits are defined/sent starting with Bit #0 defined below. Additional 144 bit definitions which may be defined in the future SHOULD be assigned 145 in ascending bit order so as to minimize the number of bits which 146 will need to be transmitted. 148 Undefined bits MUST be transmitted as 0 and MUST be 149 ignored on receipt. 151 Bits which are NOT transmitted MUST be treated as if they are 152 set to 0 on receipt. 154 X-Flag: External Prefix Flag (Bit 0) 155 Set if the prefix has been redistributed from another protocol. 156 This includes the case where multiple virtual routers are 157 supported and the source of the redistributed prefix is another 158 IS-IS instance. 159 The flag MUST be preserved when leaked between levels. 160 In TLVs 236 and 237 this flag SHOULD always be sent as 0 and 161 MUST be ignored on receipt. This is because there is an existing 162 X flag defined in the fixed format of these TLVs as specified in 163 [RFC5308] and [RFC5120]. 165 R-Flag: Re-advertisement Flag (Bit 1) 166 Set when the prefix has been leaked from one level to another 167 (upwards or downwards). 169 N-flag: Node Flag (Bit 2) 170 Set when the prefix identifies the advertising router i.e., the 171 prefix is a host prefix advertising a globally reachable address 172 typically associated with a loopback address. 173 The advertising router MAY choose to NOT set this flag even when 174 the above conditions are met. 175 If the flag is set and the prefix length is NOT a host prefix 176 (/32 for IPV4, /128 for IPv6) then the flag MUST be ignored. 177 The flag MUST be preserved when leaked between levels. 179 2.2. IPv4/IPv6 Source Router ID 181 When a reachability advertisement is leaked from one level to 182 another, the source of the original advertisement is unknown. In 183 cases where the advertisement is an identifier for the advertising 184 router (e.g., N-flag set in the Extended Reachability Attribute sub- 185 TLV as described in the previous section) it may be useful for other 186 routers to know the source of the advertisement. The sub-TLVs 187 defined below provide this information. 189 Note that the Router ID advertised is always the Router ID of the IS- 190 IS instance which originated the advertisement. This would be true 191 even if the prefix has been learned from another protocol (X-flag set 192 as defined in Section 2.1). 194 IPv4 Source Router ID 195 Type: 11 (suggested - to be assigned by IANA) 196 Length: 4 197 Value: IPv4 Router ID of the source of the advertisement 199 Inclusion of this TLV is optional and MAY occur in TLVs 200 135, 235, 236, or 237. When included the value MUST be 201 identical to the value advertised in Traffic Engineering 202 router ID (TLV 134) defined in [RFC5305]. 204 If present the sub-TLV MUST be included when the prefix 205 advertisement is leaked to another level. 207 IPv6 Source Router ID 208 Type: 12 (suggested - to be assigned by IANA) 209 Length: 16 210 Value: IPv6 Router ID of the source of the advertisement 212 Inclusion of this TLV is optional and MAY occur in TLVs 213 135, 235, 236, or 237. When included the value MUST be 214 identical to the value advertised in IPv6 TE Router ID 215 (TLV 140) defined in [RFC6119]. 217 If present the sub-TLV MUST be included when the prefix 218 advertisement is leaked to another level. 220 2.3. Advertising Router IDs 222 [RFC5305] and [RFC6119] define the advertisement of router IDs for 223 IPv4 and IPv6 respectively. Although both drafts discuss the use of 224 router ID in the context of Traffic Engineering (TE), the 225 advertisement of router IDs is explicitly allowed for purposes other 226 than TE. The use of router IDs to identify the source of a prefix 227 advertisement as defined in the previous section is one such use 228 case. Therefore, whenever the source router ID sub-TLVs defined in 229 the previous section are used, the originating router SHOULD also 230 advertise the corresponding address-family specific router ID TLV(s). 232 3. IANA Considerations 234 This document adds the following new sub-TLVs to the registry of sub- 235 TLVs for TLVs 135, 235, 236, 237. 237 Value: 4 (suggested - to be assigned by IANA) 239 Name: Prefix Attribute Flags 241 Value: 11 (suggested - to be assigned by IANA) 243 Name: IPv4 Source Router ID 245 Value: 12 (suggested - to be assigned by IANA) 247 Name: IPv6 Source Router ID 249 This document also introduces a new registry for bit values in the 250 Prefix Attribute Flags sub-TLV. Registration policy is Expert Review 251 as defined in [RFC5226]. This registry is to be part of the IS-IS 252 TLV Codepoints registry. The name of the registry is "Bit values for 253 Prefix Attribute Flags sub-TLV". Defined values are: 255 Bit # Name 256 ----- ------------------------ 257 0 External Prefix Flag (X-flag) 258 1 Re-advertisement Flag (R-flag) 259 2 Node Flag (N-flag) 261 4. Security Considerations 263 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 265 Advertisement of the additional information defined in this document 266 introduces no new security concerns. 268 5. Contributors 270 The following people gave a substantial contribution to the content 271 of this document and should be considered as co-authors: 273 Clarence Filsfils 274 Cisco Systems 276 Email: cf@cisco.com 278 Stephane Litkowski 279 Orange Business Service 281 Email: stephane.litkowski@orange.com 283 6. References 285 6.1. Normative References 287 [ISO10589] 288 International Organization for Standardization, 289 "Intermediate system to Intermediate system intra-domain 290 routeing information exchange protocol for use in 291 conjunction with the protocol for providing the 292 connectionless-mode Network Service (ISO 8473)", ISO/ 293 IEC 10589:2002, Second Edition, Nov 2002. 295 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 296 dual environments", RFC 1195, DOI 10.17487/RFC1195, 297 December 1990, . 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 305 Topology (MT) Routing in Intermediate System to 306 Intermediate Systems (IS-ISs)", RFC 5120, 307 DOI 10.17487/RFC5120, February 2008, 308 . 310 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 311 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 312 DOI 10.17487/RFC5226, May 2008, 313 . 315 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 316 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 317 2008, . 319 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 320 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 321 2008, . 323 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 324 DOI 10.17487/RFC5308, October 2008, 325 . 327 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 328 and M. Fanto, "IS-IS Generic Cryptographic 329 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 330 2009, . 332 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 333 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 334 February 2011, . 336 6.2. Informational References 338 [SR] "IS-IS Extensions for Segment Routing, draft-ietf-isis- 339 segment-routing-extensions-06(work in progress)", December 340 2015. 342 Authors' Addresses 344 Les Ginsberg (editor) 345 Cisco Systems 346 510 McCarthy Blvd. 347 Milpitas, CA 95035 348 USA 350 Email: ginsberg@cisco.com 352 Bruno Decraene 353 Orange 354 38 rue du General Leclerc 355 Issy Moulineaux cedex 9 92794 356 France 358 Email: bruno.decraene@orange.com 359 Stefano Previdi 360 Cisco Systems 361 Via Del Serafico 200 362 Rome 0144 363 Italy 365 Email: sprevidi@cisco.com 367 Xiaohu Xu 368 Huawei 370 Email: xuxiaohu@huawei.com 372 Uma Chunduri 373 Ericsson 375 Email: uma.chunduri@ericsson.com