idnits 2.17.00 (12 Aug 2021) /tmp/idnits10679/draft-ietf-isis-admin-tags-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 preceeds 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 2119' on line 56 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** 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 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Christian Martin 3 INTERNET DRAFT Verizon Internet Services 4 Expiration Date: January 2003 Brad Neal 5 Broadwing Communications 6 Stefano Previdi 7 August 2002 Cisco Systems 9 A Policy Control Mechanism is IS-IS Using Administrative Tags 10 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Abstract 35 This document describes an extension to the IS-IS protocol to add 36 operational capabilities that allow for ease of management and 37 control over IP prefix distribution within an IS-IS domain. The IS- 38 IS protocol is specified in [1], with extensions for supporting IPv4 39 specified in [2] and further enhancements for Traffic Engineering [4] 40 in [3] and [6]. 42 This document enhances the IS-IS protocol by extending the 43 information that a Intermediate System (IS) [router] can place in 44 Link State Protocol Data Units (LSPs) as specified in [2]. This 45 extension will provide operators with a mechanism to control IP 46 prefix distribution throughout multi-level IS-IS domains. 47 Additionally, the information can be placed in LSPs that have TLVs as 48 yet undefined, if this information is used to convey the same meaning 49 in these future TLVs as it is used in the currently defined TLVs. 51 3. Specification of Requirements 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC 2119]. 57 4. Introduction 59 As defined in [2] and extended in [3], the IS-IS protocol may be used 60 to distribute IP prefix reachibility information throughout an IS-IS 61 domain. The IP prefix information is encoded as TLV type 128 and 130 62 in [2], with additional information carried in TLV 135 as specified 63 in [3] and TLV 235 as defined in [6]. In particular, the extended IP 64 Reachabilty TLV (135) contains support for a larger metric space, an 65 up/down bit to indicate redistribution between different levels in 66 the hierarchy, an IP prefix, and one or more sub-TLVs that can be 67 used to carry specific information about the prefix. TLV 235 is a 68 derivative of TLV 135, with the addition of MultiTopology membership 69 information [6]. 71 As of this writing no sub-TLVs have been defined; however, this draft 72 proposes 2 new sub-TLVs for both TLV 135 and TLV 235 that may be used 73 to carry administrative information about an IP prefix. 75 5. Sub-TLV Additions 77 This draft proposes 2 new "Administrative Tag" sub-TLVs to be added 78 to TLV 135 and 235. These TLVs specify one or more ordered, 32 or 64 79 bit unsigned integers that may be associated with an IP prefix. 80 Example uses of these tags include controlling redistribution between 81 levels and areas, different routing protocols, or multiple instances 82 of IS-IS running on the same router, or carrying BGP standard or 83 extended communites. 85 The methods for which their use is employed is beyond the scope of 86 this document and left to the implementer and/or operator. 88 The encoding of the sub-TLV(s) is discussed in the following 89 subsections. 91 5.1. 32-bit Administrative Tag Sub-TLV 1 93 The Administrative Tag shall be encoded as one or more 4 octet 94 unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The 95 Administrative Tag Sub-TLV has following structure: 97 1 octet of type (value: 1) 98 1 octet of length (value: multiple of 4) 99 one or more instances of 4 octets of administrative tag 101 An implementation may consider only one of the encoded tags, in which 102 case the first encoded tag must be considered. A tag value of zero 103 is reserved and should be treated as "no tag". 105 5.2. 64-bit Administrative Tag Sub-TLV 2 107 The Administrative Tag shall be encoded as one or more 8 octet 108 unsigned integers using Sub-TLV 2 in TLV-135 [3] and TLV 235 [6]. The 109 64-bit Administrative Tag Sub-TLV has following structure: 111 1 octet of type (value: 1) 112 1 octet of length (value: multiple of 8) 113 one or more instances of 8 octets of administrative tag 115 An implementation may consider only one of the encoded tags, in which 116 case the first encoded tag must be considered. A tag value of zero 117 is reserved and should be treated as "no tag". 119 6. Ordering of Tags 121 The semantics of the tag order are implementation-dependent. That 122 is, there is no implied meaning to the ordering of the tags that 123 indicates a certain operation or set of operations need be performed, 124 based on the order of the tags. Each tag SHOULD be treated as an 125 autonomous identifier that MAY be used in policy to perform a policy 126 action. Whether or not tag A preceeds or succeeds tag B SHOULD not 127 change the meaning of the tag set. However, an implementation MAY 128 wish to preserve tag ordering such that an ordered set of tags has 129 meaning to the local policy. 131 Each IS that receives an LSP with TLV(s) 135 and/or 235, that have 132 associated SubTLV(s) 1 and/or 2, MAY operate on the tag values as 133 warranted by the implementation. If an implementation needs to 134 change tag values, for example, at an area boundary, then the TLV(s) 135 SHOULD be copied to the newly generated Level-1 or Level-2 LSP at 136 which point, the contents of the SubTLV(s) MAY change as dictated by 137 the policy action. In the event that no change is required, the 138 SubTLV(s) SHOULD be copied in order into the new LSP, such that 139 ordering is preserved. 141 7. A compliant IS-IS implementation: 143 MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or 144 235. 146 MAY be able to assign more than one tag to any IP prefix in TLV(s) 147 135 and/or 235. 149 MAY be able to rewrite or remove one or more tags associated with a 150 prefix in TLV(s) 135 and/or 235 upon LSP generation at an area 151 boundary. 153 8. Operation 155 An administrator associates an Administrative Tag value with some 156 interesting property. When IS-IS advertises reachability for some IP 157 prefix that has that property, it adds the Administrative Tag to the 158 IP reachability information TLV for that prefix, and the tag "sticks" 159 to the prefix as it is flooded throughout the routing domian. 161 Consider the network in figure 1. We wish to "leak" L1 prefixes [5] 162 with some property, A, from L2 to the L1 router R1. Without policy- 163 groups, there is no way for R2 to know property A prefixes from 164 property B prefixes. 166 R2--------R3--------R4 167 L2 / \ 168 - - - /- - - - - - - - - - - - - - 169 L1 / \ 170 R5----1.1.1.0/24 (A) R5 171 | 172 | 173 1.1.2.0/24 (B) 175 Figure 1 177 We associate Administrative Tag 100 with property A, and have R5 178 attach that value to the IP extended reachability information TLV for 179 prefix 1.1.1.0/24. R2 has a policy in place to "match prefixes with 180 Administrative Tag 100, and leak to L1." 182 The previous example is rather simplistic; it seems that it would be 183 just as easy for R2 simply to match the prefix 1.1.1.0/24. However, 184 if there are a large number of routers that need to apply some policy 185 according to property A and large number of "A" prefixes, this 186 mechanism can be quite helpful. 188 9. Security Considerations 190 This document raises no new security issues for IS-IS, as any 191 annotations to IP prefixes should not pass outside the administrative 192 control of the network operator of the IS-IS domain. Such an 193 allowance would violate the spirit of Interior Gateway Protocols in 194 general and IS-IS in particular. 196 10. IANA Considerations 198 The authors have chosen "1" as the typecode of the 32-bit 199 Administrative Tag sub-TLV and "2" as the typecode of the 64-bt 200 Administrative Tag SubTLV. These values must be allocated by IANA. 202 11. Acknowledgments 204 The authors would like to thank Henk Smit for clarifying the best 205 place to describe this new information, Tony Li and Tony Przygienda 206 for useful comments on this draft, Danny McPherson for some much 207 needed formatting assistance, and Mike Shand for useful discussions 208 on encoding structure of the sub-TLV. 210 12. References 212 [1] "Intermediate System to Intermediate System Intra-Domain Routeing 213 Exchange Protocol for use in Conjunction with the Protocol for 214 Providing the Connectionless-mode Network Service (ISO 8473)", 215 ISO 10589. 217 [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and 218 dual environments", RFC 1195, December 1990. 220 [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering", 221 Internet Draft, "Work in Progress", September 2000. 223 [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, 224 J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, 225 September 1999. 227 [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution 228 with Two-Level IS-IS" RFC 2966, October 2000 230 [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology 231 Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April 232 2002. 234 13. Authors' Address 236 Christian Martin 237 Verizon Internet Services 238 1880 Campus Commons Dr 239 Reston, VA 20191 240 Email: cmartin@gnilink.net 242 Brad Neal 243 Broadwing Communications 244 1835 Kramer Lane - Suite 100 245 Austin, TX 78758 246 USA 247 Email: bneal@broadwing.com 249 Stefano Previdi 250 Cisco Systems, Inc. 251 De Kleetlaan 6A 252 1831 Diegem - Belgium 253 email: sprevidi@cisco.com