idnits 2.17.1 draft-ginsberg-isis-prefix-attributes-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 : ---------------------------------------------------------------------------- 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 06, 2014) is 3484 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track B. Decraene 5 Expires: April 9, 2015 Orange 6 C. Filsfils 7 Cisco Systems 8 S. Litkowski 9 Orange Business Service 10 S. Previdi 11 Cisco Systems 12 October 06, 2014 14 IS-IS Prefix Attributes for Extended IP and IPv6 Reachability 15 draft-ginsberg-isis-prefix-attributes-00.txt 17 Abstract 19 This document introduces new sub-TLVs to support advertisement of 20 prefix attribute flags and the source router id of the router which 21 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 April 9, 2015. 46 Copyright Notice 48 Copyright (c) 2014 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 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 76 2. New sub-TLVs for Extended Reachability TLVs . . . . . . . . . 3 77 2.1. IPv4/IPv6 Extended Reachability Attribute Flags . . . . . 3 78 2.2. IPv4/IPv6 Source Router ID . . . . . . . . . . . . . . . 4 79 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 81 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 84 6.2. Informational References . . . . . . . . . . . . . . . . 6 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 87 1. Introduction 89 There are existing use cases in which knowing additional attributes 90 of a prefix is useful. For example, it is useful to know whether an 91 advertised prefix is directly connected to the advertising router or 92 not. In the case of [SR] knowing whether a prefix is directly 93 connected or not determines what action should be taken as regards 94 processing of labels associated with an incoming packet. Current 95 formats of the Extended Reachability TLVs for both IP and IPv6 are 96 fixed and do not allow the introduction of additional flags without 97 backwards compatibility issues. Therefore a new sub-TLV is 98 introduced which allows for the advertisement of attribute flags 99 associated with prefix advertisements. 101 It is also useful to know the source of a prefix advertisement when 102 the advertisement has been leaked to another level. Therefore a new 103 sub-TLV is introduced to advertise the router-id of the originator of 104 a prefix advertisement. 106 2. New sub-TLVs for Extended Reachability TLVs 108 The following new sub-TLVs are introduced: 110 o IPv4/IPv6 Extended Reachability Attributes 112 o IPv4 Source Router ID 114 o IPv6 Source Router ID 116 All sub-TLVs are applicable to TLVs 135, 235, 236, and/or 237. 118 2.1. IPv4/IPv6 Extended Reachability Attribute Flags 120 This sub-TLV supports the advertisement of additional flags 121 associated with a given prefix advertisement. When a prefix 122 advertisement is leaked from one level to another (upwards or 123 downwards) the state of a given flag is either preserved or set to 0. 124 The behavior of each flag is explicitly defined below. 126 All flags are applicable to TLVs 135, 235, 236, 237 unless otherwise 127 stated. 129 Prefix Attribute Flags 130 Type: 4 (suggested - to be assigned by IANA) 131 Length: Number of octets to follow 132 Value 134 (Length * 8) bits. 136 0 1 2 3 4 5 6 7... 137 +-+-+-+-+-+-+-+-+... 138 |X|R|N| ... 139 +-+-+-+-+-+-+-+-+... 141 Bits are defined/sent starting with Bit #0 defined below. Additional 142 bit definitions which may be defined in the future SHOULD be assigned 143 in ascending bit order so as to minimize the number of bits which 144 will need to be transmitted. 146 X-Flag: External Prefix Flag (Bit 0) 147 Set if the prefix has been redistributed from another protocol. 148 This includes the case where multiple virtual routers are 149 supported and the source of the redistributed prefix is another 150 IS-IS instance. 151 The flag is preserved when leaked between levels. 152 In TLVs 236 and 237 this flag SHOULD always be sent as 0 and 153 MUST be ignored on receipt. This is because there is an existing 154 X flag defined in the fixed format of these TLVs as specified in 155 [RFC5308] and [RFC5120]. 157 R-Flag: Re-advertisement Flag (Bit 1) 158 Set when the prefix has been leaked from one level to another 159 (upwards or downwards). 161 N-flag: Node Flag (Bit 2) 162 Set when the prefix identifies the advertising router i.e., the 163 prefix is a host prefix advertising a globally reachable address 164 typically associated with a loopback address. 165 The advertising router MAY choose to NOT set this flag even when 166 the above conditions are met. 167 If the flag is set and the prefix length is NOT a host prefix 168 (/32 for IPV4, /128 for IPv6) then the flag MUST be ignored. 169 The flag is preserved when leaked between levels. 171 2.2. IPv4/IPv6 Source Router ID 173 When a reachability advertisement is leaked from one level to 174 another, the source of the original advertisement is unknown. In 175 cases where the advertisement is an identifier for the advertising 176 router (e.g., N-flag set in the Extended Reachability Attribute sub- 177 TLV as described in the previous section) it may be useful for other 178 routers to know the source of the advertisement. The sub-TLVs 179 defined below provide this information. 181 IPv4 Source Router ID 182 Type: 11 (suggested - to be assigned by IANA) 183 Length: 4 184 Value: IPv4 Router ID of the source of the advertisement 186 Inclusion of this TLV is optional and MAY occur in TLVs 187 135, 235, 236, or 237. 189 If present the sub-TLV MUST be included when the prefix 190 advertisement is leaked to another level. 192 IPv6 Source Router ID 193 Type: 12 (suggested - to be assigned by IANA) 194 Length: 16 195 Value: IPv6 Router ID of the source of the advertisement 197 Inclusion of this TLV is optional and MAY occur in TLVs 198 135, 235, 236, or 237. 200 If present the sub-TLV MUST be included when the prefix 201 advertisement is leaked to another level. 203 3. IANA Considerations 205 This document adds the following new sub-TLVs to the registry of sub- 206 TLVs for TLVs 135, 235, 236, 237. 208 Value: 4 (suggested - to be assigned by IANA) 210 Name: Prefix Attribute Flags 212 Value: 11 (suggested - to be assigned by IANA) 214 Name: IPv4 Source Router ID 216 Value: 12 (suggested - to be assigned by IANA) 218 Name: IPv6 Source Router ID 220 This document also introduces a new registry for bit values in the 221 Prefix Attribute Flags sub-TLV. Registration policy is Expert Review 222 as defined in [RFC5226]. Defined values are: 224 Bit # Name 225 ----- ------------------------ 226 0 External Prefix Flag 227 1 Re-advertisement Flag 228 2 Node Flag 230 4. Security Considerations 232 None. 234 5. Acknowledgements 236 TBD 238 6. References 240 6.1. Normative References 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 245 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 246 Topology (MT) Routing in Intermediate System to 247 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 249 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 250 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 251 May 2008. 253 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 254 2008. 256 6.2. Informational References 258 [SR] "IS-IS Extensions for Segment Routing, draft-ietf-isis- 259 segment-routing-extensions-02(work in progress)", June 260 2014. 262 Authors' Addresses 264 Les Ginsberg 265 Cisco Systems 266 510 McCarthy Blvd. 267 Milpitas, CA 95035 268 USA 270 Email: ginsberg@cisco.com 271 Bruno Decraene 272 Orange 273 38 rue du General Leclerc 274 MIssy Moulineaux cedex 9 92794 275 France 277 Email: bruno.decraene@orange.com 279 Clarence Filsfils 280 Cisco Systems 282 Email: cfilsfils@cisco.com 284 Stephane Litkowski 285 Orange Business Service 287 Email: stephane.litkowski@orange.com 289 Stefano Previdi 290 Cisco Systems 291 Via Del Serafico 200 292 Rome 0144 293 Italy 295 Email: sprevidi@cisco.com