idnits 2.17.1 draft-ietf-isis-admin-tags-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 383. 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The semantics of the tag order are implementation-dependent. That is, there is no implied meaning to the ordering of the tags that indicates a certain operation or set of operations need be performed based on the order of the tags. Each tag SHOULD be treated as an autonomous identifier that MAY be used in policy to perform a policy action. Whether or not tag A precedes or succeeds tag B SHOULD not change the meaning of the tag set. However, when propagating TLVs containing multiple tags between levels, an implementation SHOULD preserve the ordering such that the first tag remains the first tag, so that implementations which only recognise a single tag will have a consistent view across levels. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 2007) is 6000 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 informational reference (is this intentional?): RFC 2966 (Obsoleted by RFC 5302) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi 3 Internet-Draft M. Shand, Ed. 4 Intended status: Standards Track Cisco Systems 5 Expires: May 22, 2008 C. Martin 6 Verizon 7 B. Neal 8 Broadwing Communications 9 November 19, 2007 11 A Policy Control Mechanism in IS-IS Using Administrative Tags 12 draft-ietf-isis-admin-tags-04.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 22, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document describes an extension to the IS-IS protocol to add 46 operational capabilities that allow for ease of management and 47 control over IP prefix distribution within an IS-IS domain. This 48 document enhances the IS-IS protocol by extending the information 49 that adraft-ietf-isis-wg-multi-topology Intermediate System (IS) 50 [router] can place in Link State Protocol Data Units (LSPs) for 51 policy use. This extension will provide operators with a mechanism 52 to control IP prefix distribution throughout multi-level IS-IS 53 domains. 55 Table of Contents 57 1. Conventions used in this Document . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Sub-TLV Additions . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. 32-bit Administrative Tag Sub-TLV 1 . . . . . . . . . . . . 4 61 3.2. 64-bit Administrative Tag Sub-TLV 2 . . . . . . . . . . . . 4 62 4. Ordering of Tags . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 9. Manageability Considerations . . . . . . . . . . . . . . . . . 7 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 Intellectual Property and Copyright Statements . . . . . . . . . . 9 75 1. Conventions used in this Document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in BCP 14, [RFC2119]. 81 2. Introduction 83 As defined in [RFC1195] and extended in [RFC3784], the IS-IS protocol 84 [ISO10589] may be used to distribute IPv4 prefix reachability 85 information throughout an IS-IS domain. In addition, thanks to 86 extensions made in [I-D.ietf-isis-wg-multi-topology] and 87 [I-D.ietf-isis-ipv6], IS-IS may be used to distribute IPv6 88 reachability information. 90 The IPv4 prefix information is encoded as TLV type 128 and 130 in 91 [RFC1195], with additional information carried in TLV 135 as 92 specified in [RFC3784] and TLV 235 as defined in 93 [I-D.ietf-isis-wg-multi-topology]. In particular, the extended IP 94 Reachability TLV (TLV 135) contains support for a larger metric 95 space, an up/down bit to indicate redistribution between different 96 levels in the hierarchy, an IP prefix, and one or more sub-TLVs that 97 can be used to carry specific information about the prefix. TLV 235 98 is a derivative of TLV 135, with the addition of Multi-Topology 99 membership information [I-D.ietf-isis-wg-multi-topology]. The IPv6 100 prefix information is encoded as TLV 236 in [I-D.ietf-isis-ipv6] and 101 TLV 237 in [I-D.ietf-isis-wg-multi-topology]. 103 This draft proposes 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 and 104 TLV 237 that may be used to carry administrative information about an 105 IP prefix. 107 3. Sub-TLV Additions 109 This draft proposes 2 new "Administrative Tag" sub-TLVs to be added 110 to TLV 135, TLV 235, TLV 236 and TLV 237. These TLVs specify one or 111 more 32 or 64 bit unsigned integers that may be associated with an IP 112 prefix. Example uses of these tags include controlling 113 redistribution between levels and areas, different routing protocols, 114 or multiple instances of IS-IS running on the same router, or 115 carrying BGP standard or extended communities. 117 The methods for which their use is employed is beyond the scope of 118 this document and left to the implementer and/or operator. 120 The encoding of the sub-TLV(s) is discussed in the following 121 subsections. 123 3.1. 32-bit Administrative Tag Sub-TLV 1 125 The Administrative Tag SHALL be encoded as one or more 4 octet 126 unsigned integers using Sub-TLV 1 in TLV-135 [RFC3784], TLV 235 127 [I-D.ietf-isis-wg-multi-topology], TLV 236 [I-D.ietf-isis-ipv6] and 128 TLV 237 [I-D.ietf-isis-wg-multi-topology]. The Administrative Tag 129 Sub-TLV has following structure: 131 o 1 octet of type (value: 1) 133 o 1 octet of length (value: multiple of 4) 135 o one or more instances of 4 octets of administrative tag 137 On receipt, an implementation MAY consider only one encoded tag, in 138 which case the first encoded tag MUST be considered and any 139 additional tags ignored. A tag value of zero is reserved and SHOULD 140 be treated as "no tag". 142 3.2. 64-bit Administrative Tag Sub-TLV 2 144 The Administrative Tag SHALL be encoded as one or more 8 octet 145 unsigned integers using Sub-TLV 2 in TLV-135 [RFC3784], TLV 235 146 [I-D.ietf-isis-wg-multi-topology], TLV 236 [I-D.ietf-isis-ipv6] and 147 TLV 237 [I-D.ietf-isis-wg-multi-topology]. The 64-bit Administrative 148 Tag Sub-TLV has following structure: 150 o 1 octet of type (value: 2) 152 o 1 octet of length (value: multiple of 8) 154 o one or more instances of 8 octets of administrative tag 156 On receipt, an implementation MAY consider only one encoded tag, in 157 which case the first encoded tag MUST be considered and any 158 additional tags ignored. A tag value of zero is reserved and SHOULD 159 be treated as "no tag". 161 4. Ordering of Tags 163 The semantics of the tag order are implementation-dependent. That 164 is, there is no implied meaning to the ordering of the tags that 165 indicates a certain operation or set of operations need be performed 166 based on the order of the tags. Each tag SHOULD be treated as an 167 autonomous identifier that MAY be used in policy to perform a policy 168 action. Whether or not tag A precedes or succeeds tag B SHOULD not 169 change the meaning of the tag set. However, when propagating TLVs 170 containing multiple tags between levels, an implementation SHOULD 171 preserve the ordering such that the first tag remains the first tag, 172 so that implementations which only recognise a single tag will have a 173 consistent view across levels. 175 Each IS that receives an LSP with TLV(s) 135 and/or 235 and/or 236 176 and/or 237, that have associated SubTLV(s) 1 and/or 2, MAY operate on 177 the tag values as warranted by the implementation. If an 178 implementation needs to change tag values, for example, when 179 propagating TLVs between levels at an area boundary, then the TLV(s) 180 SHOULD be copied to the newly generated Level-1 or Level-2 LSP at 181 which point, the contents of the SubTLV(s) MAY change as dictated by 182 the policy action. In the event that no change is required, the 183 SubTLV(s) SHOULD be copied in order into the new LSP, such that 184 ordering is preserved. 186 5. Compliance 188 A compliant IS-IS implementation MUST be able to assign one tag to 189 any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 190 236, TLV 237. It MUST be able to interpret a single tag present in 191 the sub-TLV, or the first tag where there is more than one tag 192 present in the sub-TLV 194 A compliant IS-IS implementation MAY be able to assign more than one 195 tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, 196 TLV 236, TLV 237. It MAY be able to interpret the second and 197 subsequent tags where more than one tag is present in the sub-TLV 199 A compliant IS-IS implementation MAY be able to rewrite or remove one 200 or more tags associated with a prefix in any of the following TLVs: 201 TLV 135, TLV 235, TLV 236, TLV 237 when propagating TLVs between 202 levels. 204 6. Operations 206 An administrator associates an Administrative Tag value with some 207 interesting property. When IS-IS advertises reachability for some IP 208 prefix that has that property, it adds the Administrative Tag to the 209 IP reachability information TLV for that prefix, and the tag "sticks" 210 to the prefix as it is flooded throughout the routing domain. 212 Consider the network in Figure 1. We wish to "leak" L1 prefixes 213 [RFC2966] with some property, A, from L2 to the L1 router R1. 215 Without policy- groups, there is no way for R2 to know property A 216 prefixes from property B prefixes. 218 R2--------R3--------R4 219 L2 / \ 220 - - - /- - - - - - - - - - - - - - 221 L1 / \ 222 R1----1.1.1.0/24 (A) R5 223 | 224 | 225 1.1.2.0/24 (B) 227 Figure 1: Example of usage 229 We associate Administrative Tag 100 with property A, and have R5 230 attach that value to the IP extended reachability information TLV for 231 prefix 1.1.2.0/24. R2 has a policy in place to "match prefixes with 232 Administrative Tag 100, and leak to L1." 234 The previous example is rather simplistic; it seems that it would be 235 just as easy for R2 simply to match the prefix 1.1.2.0/24. However, 236 if there are a large number of routers that need to apply some policy 237 according to property A and large number of "A" prefixes, this 238 mechanism can be quite helpful. 240 Implementations which support only a single tag and those which 241 support multiple tags may co-exist in the same IS-IS domain. An 242 implementatation supporting multiple tags SHOULD therefor assign any 243 tag which is required to be interpretted by all systems as the first 244 tag in any set of multiple tags. 246 7. Security Considerations 248 This document raises no new security issues for IS-IS, as any 249 annotations to IP prefixes should not pass outside the administrative 250 control of the network operator of the IS-IS domain. Such an 251 allowance would violate the spirit of Interior Gateway Protocols in 252 general and IS-IS in particular 254 8. IANA Considerations 256 The authors have chosen "1" as the type code of the 32-bits 257 Administrative Tag Sub-TLV and "2" as the type code of the 64-bits 258 Administrative Tag Sub-TLV. These values must be allocated by IANA. 260 9. Manageability Considerations 262 These extensions which have been designed, developed and deployed for 263 many years do not have any new impact on management and operation of 264 the ISIS protocol via this standardization process. 266 10. Acknowledgements 268 The authors would like to thank Henk Smit for clarifying the best 269 place to describe this new information, Tony Li and Tony Przygienda 270 for useful comments on this draft, Danny McPherson for some much 271 needed formatting assistance. 273 11. References 275 11.1. Normative References 277 [ISO10589] 278 International Organization for Standardization, 279 "Intermediate system to Intermediate system intra-domain 280 routeing information exchange protocol for use in 281 conjunction with the protocol for providing the 282 connectionless-mode Network Service (ISO 8473)", ISO/ 283 IEC 10589:2002, Second Edition, Nov 2002. 285 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 286 dual environments", RFC 1195, December 1990. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 11.2. Informative References 293 [I-D.ietf-isis-ipv6] 294 Hopps, C., "Routing IPv6 with IS-IS", 295 draft-ietf-isis-ipv6-07 (work in progress), October 2007. 297 [I-D.ietf-isis-wg-multi-topology] 298 Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in 299 IS-IS", draft-ietf-isis-wg-multi-topology-12 (work in 300 progress), November 2007. 302 [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix 303 Distribution with Two-Level IS-IS", RFC 2966, 304 October 2000. 306 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 307 System (IS-IS) Extensions for Traffic Engineering (TE)", 308 RFC 3784, June 2004. 310 Authors' Addresses 312 Stefano Previdi 313 Cisco Systems 314 Via Del Serafico, 200 315 00142 Rome, 316 Italy 318 Email: sprevidi@cisco.com 320 Mike Shand (editor) 321 Cisco Systems 322 250, Longwater Avenue. 323 Reading, Berks RG2 6GB 324 UK 326 Phone: +44 208 824 8690 327 Email: mshand@cisco.com 329 Christian Martin 330 Verizon 331 1880 Campus Commons Dr 332 Reston, VA 20191 333 USA 335 Email: cmartin@verizon.com 337 Brad Neal 338 Broadwing Communications 339 1835 Kramer Lane - Suite 100 340 Austin, TX 78758 341 USA 343 Email: bneal@broadwing.com 345 Full Copyright Statement 347 Copyright (C) The IETF Trust (2007). 349 This document is subject to the rights, licenses and restrictions 350 contained in BCP 78, and except as set forth therein, the authors 351 retain all their rights. 353 This document and the information contained herein are provided on an 354 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 355 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 356 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 357 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 358 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 361 Intellectual Property 363 The IETF takes no position regarding the validity or scope of any 364 Intellectual Property Rights or other rights that might be claimed to 365 pertain to the implementation or use of the technology described in 366 this document or the extent to which any license under such rights 367 might or might not be available; nor does it represent that it has 368 made any independent effort to identify any such rights. Information 369 on the procedures with respect to rights in RFC documents can be 370 found in BCP 78 and BCP 79. 372 Copies of IPR disclosures made to the IETF Secretariat and any 373 assurances of licenses to be made available, or the result of an 374 attempt made to obtain a general license or permission for the use of 375 such proprietary rights by implementers or users of this 376 specification can be obtained from the IETF on-line IPR repository at 377 http://www.ietf.org/ipr. 379 The IETF invites any interested party to bring to its attention any 380 copyrights, patents or patent applications, or other proprietary 381 rights that may cover technology that may be required to implement 382 this standard. Please address the information to the IETF at 383 ietf-ipr@ietf.org. 385 Acknowledgment 387 Funding for the RFC Editor function is provided by the IETF 388 Administrative Support Activity (IASA).