idnits 2.17.00 (12 Aug 2021) /tmp/idnits10294/draft-ietf-isis-admin-tags-03.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 3667, Section 5.1 on line 241. -- Found old boilerplate from RFC 3978, Section 5.5 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 228. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 6) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 125 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == 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 RFC 3978 Section 5.4 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, an implementation MAY wish to preserve tag ordering such that an ordered set of tags has meaning to the local policy. -- 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 (February 2005) is 6303 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) == Unused Reference: 'RFC' is defined on line 255, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 261, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 264, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 273, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 3784 (ref. '3') (Obsoleted by RFC 5305) ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. '4') ** Obsolete normative reference: RFC 2966 (ref. '5') (Obsoleted by RFC 5302) == Outdated reference: draft-ietf-isis-wg-multi-topology has been published as RFC 5120 == Outdated reference: draft-ietf-isis-ipv6 has been published as RFC 5308 Summary: 16 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IS-IS Working Group Christian Martin 2 Verizon 3 IETF Internet Draft Stefano Previdi 4 Cisco Systems 5 Brad Neal 6 Broadwing Communications 8 Expires: August 2005 February 2005 10 A Policy Control Mechanism in IS-IS Using Administrative Tags 12 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or IPR claims of which I am aware have been disclosed, and any 18 of which I become aware will be disclosed, in accordance with RFC 19 3668. 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet- Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document describes an extension to the IS-IS protocol to add 41 operational capabilities that allow for ease of management and 42 control over IP prefix distribution within an IS-IS domain. This 43 document enhances the IS-IS protocol by extending the information 44 that a Intermediate System (IS) [router] can place in Link State 45 Protocol Data Units (LSPs) for policy use. This extension will 46 provide operators with a mechanism to control IP prefix distribution 47 throughout multi-level IS-IS domains. Additionally, the information 48 can be placed in LSPs that have TLVs as yet undefined, if this 49 information is used to convey the same meaning in these future TLVs 50 as it is used in the currently defined TLVs. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119. 58 1. Introduction 60 As defined in [2] and extended in [3], the IS-IS protocol may be used 61 to distribute IPv4 prefix reachability information throughout an IS- 62 IS domain. In addition, thanks to extensions made in [6] and [7], IS- 63 IS may be used to distribute IPv6 reachability information. 65 The IPv4 prefix information is encoded as TLV type 128 and 130 in 66 [2], with additional information carried in TLV 135 as specified in 67 [3] and TLV 235 as defined in [6]. In particular, the extended IP 68 Reachability TLV (TLV 135) contains support for a larger metric 69 space, an up/down bit to indicate redistribution between different 70 levels in the hierarchy, an IP prefix, and one or more sub-TLVs that 71 can be used to carry specific information about the prefix. TLV 235 72 is a derivative of TLV 135, with the addition of Multi-Topology 73 membership information [6]. The IPv6 prefix information is encoded as 74 TLV 236 in [7] and TLV 237 in [6]. 76 As of this writing no sub-TLVs have been defined; however, this draft 77 proposes 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 and TLV 237 78 that may be used to carry administrative information about an IP 79 prefix. 81 2. Sub-TLV Additions 83 This draft proposes 2 new "Administrative Tag" sub-TLVs to be added 84 to TLV 135, TLV 235, TLV 236 and TLV 237. These TLVs specify one or 85 more ordered, 32 or 64 bit unsigned integers that may be associated 86 with an IP prefix. Example uses of these tags include controlling 87 redistribution between levels and areas, different routing protocols, 88 or multiple instances of IS-IS running on the same router, or 89 carrying BGP standard or extended communities. 91 The methods for which their use is employed is beyond the scope of 92 this document and left to the implementer and/or operator. 94 The encoding of the sub-TLV(s) is discussed in the following 95 subsections. 97 2.1. 32-bit Administrative Tag Sub-TLV 1 99 The Administrative Tag SHALL be encoded as one or more 4 octet 100 unsigned integers using Sub-TLV 1 in TLV-135 [3], TLV 235 [6], TLV 101 236 [7] and TLV 237 [6]. The Administrative Tag Sub-TLV has following 102 structure: 104 1 octet of type (value: 1) 105 1 octet of length (value: multiple of 4) 106 one or more instances of 4 octets of administrative tag 108 An implementation MAY consider only one of the encoded tags, in which 109 case the first encoded tag MUST be considered. A tag value of zero 110 is reserved and SHOULD be treated as "no tag". 112 2.2. 64-bit Administrative Tag Sub-TLV 2 114 The Administrative Tag SHALL be encoded as one or more 8 octet 115 unsigned integers using Sub-TLV 2 in TLV-135 [3], TLV 235 [6], TLV 116 236 [7] and TLV 237 [6]. The 64-bit Administrative Tag Sub-TLV has 117 following structure: 119 1 octet of type (value: 2) 120 1 octet of length (value: multiple of 8) 121 one or more instances of 8 octets of administrative tag 123 An implementation MAY consider only one of the encoded tags, in which 124 case the first encoded tag MUST be considered. A tag value of zero 125 is reserved and SHOULD be treated as "no tag". 127 3. Ordering of Tags 129 The semantics of the tag order are implementation-dependent. That 130 is, there is no implied meaning to the ordering of the tags that 131 indicates a certain operation or set of operations need be performed 132 based on the order of the tags. Each tag SHOULD be treated as an 133 autonomous identifier that MAY be used in policy to perform a policy 134 action. Whether or not tag A precedes or succeeds tag B SHOULD not 135 change the meaning of the tag set. However, an implementation MAY 136 wish to preserve tag ordering such that an ordered set of tags has 137 meaning to the local policy. 139 Each IS that receives an LSP with TLV(s) 135 and/or 235 and/or 236 140 and/or 237, that have associated SubTLV(s) 1 and/or 2, MAY operate on 141 the tag values as warranted by the implementation. If an 142 implementation needs to change tag values, for example, at an area 143 boundary, then the TLV(s) SHOULD be copied to the newly generated 144 Level-1 or Level-2 LSP at which point, the contents of the SubTLV(s) 145 MAY change as dictated by the policy action. In the event that no 146 change is required, the SubTLV(s) SHOULD be copied in order into the 147 new LSP, such that ordering is preserved. 149 4. Compliance 151 A compliant IS-IS implementation MUST be able to assign one tag to 152 any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 153 236, TLV 237. 155 A compliant IS-IS implementation MAY be able to assign more than one 156 tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, 157 TLV 236, TLV 237. 159 A compliant IS-IS implementation MAY be able to rewrite or remove one 160 or more tags associated with a prefix in any of the following TLVs: 161 TLV 135, TLV 235, TLV 236, TLV 237. 163 5. Operations 165 An administrator associates an Administrative Tag value with some 166 interesting property. When IS-IS advertises reachability for some IP 167 prefix that has that property, it adds the Administrative Tag to the 168 IP reachability information TLV for that prefix, and the tag "sticks" 169 to the prefix as it is flooded throughout the routing domain. 171 Consider the network in figure 1. We wish to "leak" L1 prefixes [5] 172 with some property, A, from L2 to the L1 router R1. Without policy- 173 groups, there is no way for R2 to know property A prefixes from 174 property B prefixes. 176 R2--------R3--------R4 177 L2 / \ 178 - - - /- - - - - - - - - - - - - - 179 L1 / \ 180 R1----1.1.1.0/24 (A) R5 181 | 182 | 183 1.1.2.0/24 (B) 185 Figure 1 187 We associate Administrative Tag 100 with property A, and have R5 188 attach that value to the IP extended reachability information TLV for 189 prefix 1.1.2.0/24. R2 has a policy in place to "match prefixes with 190 Administrative Tag 100, and leak to L1." 192 The previous example is rather simplistic; it seems that it would be 193 just as easy for R2 simply to match the prefix 1.1.2.0/24. However, 194 if there are a large number of routers that need to apply some policy 195 according to property A and large number of "A" prefixes, this 196 mechanism can be quite helpful. 198 6. Security Considerations 200 This document raises no new security issues for IS-IS, as any 201 annotations to IP prefixes should not pass outside the administrative 202 control of the network operator of the IS-IS domain. Such an 203 allowance would violate the spirit of Interior Gateway Protocols in 204 general and IS-IS in particular 206 7. IANA Considerations 208 The authors have chosen "1" as the type code of the 32-bits 209 Administrative Tag Sub-TLV and "2" as the type code of the 64-bits 210 Administrative Tag Sub-TLV. These values must be allocated by IANA. 212 8. Intellectual Property Statement 214 The IETF takes no position regarding the validity or scope of any 215 Intellectual Property Rights or other rights that might be claimed to 216 pertain to the implementation or use of the technology described in 217 this document or the extent to which any license under such rights 218 might or might not be available; nor does it represent that it has 219 made any independent effort to identify any such rights. Information 220 on the procedures with respect to rights in RFC documents can be 221 found in BCP 78 and BCP 79. 223 Copies of IPR disclosures made to the IETF Secretariat and any 224 assurances of licenses to be made available, or the result of an 225 attempt made to obtain a general license or permission for the use of 226 such proprietary rights by implementers or users of this 227 specification can be obtained from the IETF on-line IPR repository at 228 http://www.ietf.org/ipr. 230 The IETF invites any interested party to bring to its attention any 231 copyrights, patents or patent applications, or other proprietary 232 rights that may cover technology that may be required to implement 233 this standard. Please address the information to the IETF at ietf- 234 ipr@ietf.org.. 236 8.1. IPR Disclosure Acknowledgement 238 By submitting this Internet-Draft, I certify that any applicable 239 patent or other IPR claims of which I am aware have been disclosed, 240 and any of which I become aware will be disclosed, in accordance with 241 RFC 3668. 243 9. Acknowledgments 245 The authors would like to thank Henk Smit for clarifying the best 246 place to describe this new information, Tony Li and Tony Przygienda 247 for useful comments on this draft, Danny McPherson for some much 248 needed formatting assistance, and Mike Shand for useful discussions 249 on encoding structure of the sub-TLV. 251 10. References 253 10.1. Normative references 255 [RFC] Bradner, S., "Key words for use in RFCs to indicate 256 requirements levels", RFC 2119, March 1997. 258 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 259 RFC 3667, February 2004. 261 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 262 Technology", BCP 79, RFC 3668, February 2004. 264 [1] "Intermediate System to Intermediate System Intra-Domain Routing 265 Exchange Protocol " ISO 10589. 267 [2] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 268 environments", RFC 1195, December 1990. 270 [3] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 271 3784, June 2004. 273 [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, 274 J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, 275 September 1999. 277 [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution 278 with Two-Level IS-IS" RFC 2966, October 2000 280 10.2. Informative References 282 [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology 283 Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April 284 2002. 286 [7] Hopps, C., "Routing IPv6 with IS-IS", draft-ietf-isis-ipv6- 287 05.txt, January 2003 289 11. Editors' Address 291 Christian Martin 292 Verizon 293 1880 Campus Commons Dr 294 Reston, VA 20191 295 Email: cmartin@verizon.com 296 Stefano Previdi 297 Cisco Systems, Inc. 298 Via Del Serafico, 200 299 00142 Roma - Italy 300 email: sprevidi@cisco.com 302 Brad Neal 303 Broadwing Communications 304 1835 Kramer Lane - Suite 100 305 Austin, TX 78758 306 USA 307 Email: bneal@broadwing.com 309 Full Copyright Statement 311 Copyright (C) The Internet Society (2005). This document is subject to 312 the rights, licenses and restrictions contained in BCP 78, and except as 313 set forth therein, the authors retain all their rights. 315 This document and the information contained herein are provided on an 316 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 317 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 318 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 319 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 320 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 321 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.