idnits 2.17.1 draft-ietf-isis-node-admin-tag-11.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 9, 2016) is 2881 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) -- Looks like a reference, but probably isn't: '1' on line 450 == Unused Reference: 'RFC5286' is defined on line 429, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) == Outdated reference: A later version (-42) exists of draft-ietf-isis-yang-isis-cfg-08 == Outdated reference: A later version (-31) exists of draft-ietf-rtgwg-policy-model-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets P. Sarkar, Ed. 3 Internet-Draft H. Gredler 4 Intended status: Standards Track Individual Contributor 5 Expires: November 10, 2016 S. Hegde 6 Juniper Networks, Inc. 7 S. Litkowski 8 B. Decraene 9 Orange 10 May 9, 2016 12 Advertising Node Administrative Tags in IS-IS 13 draft-ietf-isis-node-admin-tag-11 15 Abstract 17 This document describes an extension to the IS-IS routing protocol to 18 add an optional capability that allows tagging and grouping of the 19 nodes in an IS-IS domain. This allows simple management and easy 20 control over route and path selection, based on local configured 21 policies. This document describes an extension to the IS-IS protocol 22 to advertise node administrative tags. The node administrative tags 23 can be used to express and apply locally defined network policies 24 which is a very useful operational capability. Node administrative 25 tags may be used either by IS-IS itself or by other applications 26 consuming information propagated via IS-IS. 28 This document describes the protocol extensions to disseminate node 29 administrative tags in IS-IS protocols. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on November 10, 2016. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Node Administrative Tags . . . . . . . . . . . . . . . . . . 3 73 3. Node Administrative Tag Sub-TLV . . . . . . . . . . . . . . . 3 74 3.1. TLV format . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 4 76 4.1. Interpretation of Node Administrative Tags . . . . . . . 5 77 4.2. Use of Node Administrative Tags . . . . . . . . . . . . . 5 78 4.3. Processing Node Administrative Tag Changes . . . . . . . 6 79 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 6 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 81 7. Operational Considerations . . . . . . . . . . . . . . . . . 7 82 8. Manageability Considerations . . . . . . . . . . . . . . . . 8 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 85 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 88 12.2. Informative References . . . . . . . . . . . . . . . . . 9 89 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 92 1. Introduction 94 It is useful to assign a node administrative tag to a router in the 95 IS-IS domain and use it as an attribute associated with the node. 97 The node administrative tag can be used in variety of applications, 98 for example: 100 (a) Traffic-engineering applications to provide different path- 101 selection criteria. 103 (b) Prefer or prune certain paths in Loop Free Alternate (LFA) 104 backup selection via local policies as defined in 105 [I-D.ietf-rtgwg-lfa-manageability]. 107 This document provides mechanisms to advertise node administrative 108 tags in IS-IS for various applications, including (but not limited 109 to) route and path selection. Route and path selection functionality 110 applies to both Traffic Engineering (TE) and non-TE applications. 111 Hence the new sub-TLV for carrying node administrative tags is 112 included in the Router CAPABILITY TLV [RFC4971]. 114 2. Node Administrative Tags 116 An administrative tag is a 32-bit unsigned integer value that can be 117 used to identify a group of nodes in the IS-IS domain. An IS-IS 118 router should advertise the set of groups it is part of in the 119 specific IS-IS level. 121 As an example, all edge network devices in a given network may be 122 configured with a certain tag value, whereas all core network devices 123 may be configured with another, different tag value. 125 3. Node Administrative Tag Sub-TLV 127 The new sub-TLV defined is carried within an IS-IS Router CAPABILITY 128 TLV (IS-IS TLV type 242) [RFC4971] in the Link State PDUs originated 129 by the device. Router CAPABILITY TLVs [RFC4971] can have 'level- 130 wide' or 'domain-wide' flooding scope. The choice of flooding scope 131 in which a specific node administrative tag shall be flooded, is 132 purely a matter of local policy, and is defined by the needs of the 133 operator's usage. An operator MAY choose to advertise a set of node 134 administrative tags across levels and another different set of node 135 administrative tags within the specific level. Alternatively, the 136 operator may use the same node administrative tags both within the 137 'domain-wide' flooding scope as well as within one or more 'level- 138 wide' flooding scope. 140 The format of the Node Administrative Tag sub-TLV (see Section 3.1) 141 does not include a topology identifier. Therefore it is not possible 142 to indicate a topology-specific context when advertising node 143 administrative tags. Hence, in deployments using multi-topology 144 routing [RFC5120], advertising a separate set of node administrative 145 tags for each topology SHOULD NOT be supported. 147 3.1. TLV format 149 [RFC4971], defines Router CAPABILITY TLV which may be used to 150 advertise properties of the originating router. The payload of the 151 Router CAPABILITY TLV consists of one or more nested Type/Length/ 152 Value (TLV) triplets. 154 The new Node Administrative Tag sub-TLV, like other IS-IS sub-TLVs, 155 is formatted as Type/Length/Value (TLV) triplets. Figure 1 below 156 shows the format of the new sub-TLV. 158 0 1 2 3 159 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Type | Length | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Administrative Tag #1 | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Administrative Tag #2 | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 // // 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Administrative Tag #N | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Type : TBA, Suggested value 21 174 ** RFC Editor** Please replace above suggested value with the IANA-assigned value. 176 Length: An 8-bit field that indicates the length of the value 177 portion in octets and will be a multiple of 4-octets 178 dependent on the number of tags advertised. 180 Value: A set of multiple 4-octets defining the node 181 administrative tags. 183 Figure 1: IS-IS Node Administrative Tag sub-TLV 185 4. Elements of Procedure 186 4.1. Interpretation of Node Administrative Tags 188 The meaning of node administrative tags is generally opaque to IS-IS. 189 A router advertising one or more node administrative tag(s) may be 190 configured to do so without knowing (or even explicitly supporting) 191 functionality implied by the tag. This section describes general 192 rules/regulations and guidelines for using and interpreting a node 193 administrative tag which will facilitate interoperable 194 implementations by vendors. 196 Interpretation of tag values is specific to the administrative domain 197 of a particular network operator. Hence tag values SHOULD NOT be 198 propagated outside the administrative domain to which they apply. 199 The meaning of a node administrative tag is defined by the network 200 local policy and is controlled via configuration. If a receiving 201 node does not understand the tag value, it ignores the specific tag 202 and floods the Router CAPABILITY TLV without any change, as defined 203 in [RFC4971]. 205 The semantics of the tag order has no meaning. There is no implied 206 meaning to the ordering of the tags that indicates a certain 207 operation or set of operations that need to be performed based on the 208 ordering. 210 Each tag SHOULD be treated as an independent identifier that may be 211 used in policy to perform a policy action. Each tag carried by the 212 Node Administrative Tag sub-TLVs should be used to indicate a 213 characteristic of a node that is independent of the characteristics 214 indicated by other administrative tags within the same or another 215 instance of a Node Administrative Tag sub-TLV. The list of Node 216 administrative tags carried in a Node Administrative Tag sub-TLV MUST 217 be considered as an unordered list. Whilst policies may be 218 implemented based on the presence of multiple tags (e.g., if tag A 219 AND tag B are present), they MUST NOT be reliant upon the order of 220 the tags (i.e., all policies should be considered commutative 221 operations, such that tag A preceding or following tag B does not 222 change their outcome). 224 4.2. Use of Node Administrative Tags 226 The node administrative tags are not meant to be extended by future 227 IS-IS standards. New IS-IS extensions are not expected to require 228 use of node administrative tags or define well-known tag values. 229 Node administrative tags are for generic use and do not require IANA 230 registry. Future IS-IS extensions requiring well-known values MAY 231 define their own data signalling tailored to the needs of the feature 232 or MAY use the capability TLV as defined in [RFC4971]. 234 Node administrative tags are expected to be associated with a stable 235 attribute. In particular, node administrative tags MUST NOT be 236 associated with something whose state can oscillate frequently, e.g., 237 the reachability of a specific destination. 239 While no specific limit on the number of node administrative tags 240 that may be advertised has been defined, it is expected that only a 241 modest number of tags will be required in any deployment. 243 4.3. Processing Node Administrative Tag Changes 245 Multiple Node Administrative Tag sub-TLVs MAY appear in a Router 246 CAPABILITY TLV or Node Administrative Tag sub-TLVs MAY be contained 247 in different instances of Router CAPABILITY TLVs. The node 248 administrative tags associated with a node that originates tags for 249 the purpose of any computation or processing at a receiving node 250 SHOULD be a superset of node administrative tags from all the TLVs in 251 all the instances of Router CAPABILITY TLVs received in the Link- 252 State PDU(s) advertised by the corresponding IS-IS router. When a 253 Router CAPABILITY TLV is received that changes the set of node 254 administrative tags applicable to any originating node, a receiving 255 node MUST repeat any computation or processing that makes use of node 256 administrative tags. 258 When there is a change or removal of an administrative affiliation of 259 a node, the node MUST re-originate the Router CAPABILITY TLV(s) with 260 the latest set of node administrative tags. On a receiving router, 261 on detecting a change in contents (or removal) of existing Node 262 Administrative Tag sub-TLV(s) or addition of new Node Administrative 263 Tag sub-TLV(s) in any instance of Router CAPABILITY TLV(s), 264 implementations MUST take appropriate measures to update their state 265 according to the changed set of node administrative tags. The exact 266 actions needed depend on features working with node administrative 267 tags and is outside of scope of this specification. 269 5. Applications 271 [RFC7777] lists several non-normative examples of how implementations 272 might use node administrative tags. These examples are given only to 273 demonstrate generic usefulness of the router tagging mechanism. An 274 implementation supporting this specification is not required to 275 implement any of the use cases. The following is a brief list of 276 non-normative use cases listed in [RFC7777]. Please refer to RFC7777 277 section 3 [1] for more details. 279 1. Auto-discovery of Services 281 2. Policy-based Fast-Re-Route (FRR) 282 (a) Administrative limitation of LFA scope 284 (b) Optimizing LFA calculations 286 3. Controlling Remote LFA tunnel termination 288 4. Mobile back-haul network service deployment 290 5. Policy-based Explicit Routing 292 6. Security Considerations 294 Node administrative tags, like link administrative tags [RFC5305], 295 can be used by operators to indicate geographical location or other 296 sensitive information. The information carried in node 297 administrative tags, like link administrative tags, can be leaked to 298 an IGP snooper. Hence this document does not introduce any new 299 security issues. 301 Advertisement of tag values for one administrative domain into 302 another involves the risk of misinterpretation of the tag values (if 303 the two domains have assigned different meanings to the same values), 304 and may have undesirable and unanticipated side effects. 306 Security concerns for IS-IS are already addressed in [ISO10589], 307 [RFC5304], and [RFC5310] and are applicable to the mechanisms 308 described in this document. Extended authentication mechanisms 309 described in [RFC5304] or [RFC5310] SHOULD be used in deployments 310 where attackers have access to the physical networks and nodes 311 included in the IS-IS domain are vulnerable. 313 7. Operational Considerations 315 Operators can assign meaning to the node administrative tags which is 316 local to the operator's administrative domain. The operational use 317 of node administrative tags is analogical to the IS-IS prefix tags 318 [RFC5130] and BGP communities [RFC1997]. Operational discipline and 319 procedures followed in configuring and using BGP communities and IS- 320 IS Prefix tags are also applicable to the usage of node 321 administrative tags. 323 Defining language for local policies is outside the scope of this 324 document. As in the case of other policy applications, the pruning 325 policies can cause the path to be completely removed from the 326 forwarding plane, and hence have the potential for more severe 327 operational impact (e.g., node unreachability due to path removal) by 328 comparison to preference policies that only affect path selection. 330 8. Manageability Considerations 332 Node administrative tags are configured and managed using routing 333 policy enhancements. YANG [RFC6020] is a data modeling language used 334 to specify configuration data models. The IS-IS YANG data model is 335 described in [I-D.ietf-isis-yang-isis-cfg] and the routing policy 336 configuration model is described in [I-D.ietf-rtgwg-policy-model]. 337 At the time of writing this document, some work to enhance these two 338 documents, to include the node administrative tag related 339 configurations, is already in progress, or shall be taken up soon. 341 9. IANA Considerations 343 This specification updates one IS-IS registry: IS-IS Router 344 CAPABILITY (TLV-242) Sub-TLVs Registry 346 i) Node-Admin-Tag Sub-TLV, Type: TBD, suggested value 21 348 ** RFC Editor** Please replace above suggested value with the IANA- 349 assigned value. 351 10. Contributors 353 Many many thanks to Ebben Aries and Rafael Rodriguez for their help 354 with reviewing and improving the text of this document. Many thanks 355 to Harish Raguveer for his contributions to initial versions of the 356 draft as well. Finally, many thanks to Li Zhenbin for providing some 357 valuable use cases. 359 11. Acknowledgments 361 Many thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri, and Chris 362 Bowers for providing useful inputs. 364 12. References 366 12.1. Normative References 368 [ISO10589] 369 "Intermediate system to Intermediate system intra-domain 370 routeing information exchange protocol for use in 371 conjunction with the protocol for providing the 372 connectionless-mode Network Service (ISO 8473), ISO/IEC 373 10589:2002, Second Edition.", Nov 2002. 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, 377 DOI 10.17487/RFC2119, March 1997, 378 . 380 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 381 "Intermediate System to Intermediate System (IS-IS) 382 Extensions for Advertising Router Information", RFC 4971, 383 DOI 10.17487/RFC4971, July 2007, 384 . 386 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 387 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 388 2008, . 390 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 391 and M. Fanto, "IS-IS Generic Cryptographic 392 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 393 2009, . 395 12.2. Informative References 397 [I-D.ietf-isis-yang-isis-cfg] 398 Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 399 Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf- 400 isis-yang-isis-cfg-08 (work in progress), March 2016. 402 [I-D.ietf-rtgwg-lfa-manageability] 403 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., and 404 M. Horneffer, "Operational management of Loop Free 405 Alternates", draft-ietf-rtgwg-lfa-manageability-11 (work 406 in progress), June 2015. 408 [I-D.ietf-rtgwg-policy-model] 409 Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, 410 "Routing Policy Configuration Model for Service Provider 411 Networks", draft-ietf-rtgwg-policy-model-01 (work in 412 progress), April 2016. 414 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 415 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 416 . 418 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 419 Topology (MT) Routing in Intermediate System to 420 Intermediate Systems (IS-ISs)", RFC 5120, 421 DOI 10.17487/RFC5120, February 2008, 422 . 424 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 425 Control Mechanism in IS-IS Using Administrative Tags", 426 RFC 5130, DOI 10.17487/RFC5130, February 2008, 427 . 429 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 430 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 431 DOI 10.17487/RFC5286, September 2008, 432 . 434 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 435 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 436 2008, . 438 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 439 the Network Configuration Protocol (NETCONF)", RFC 6020, 440 DOI 10.17487/RFC6020, October 2010, 441 . 443 [RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. 444 Decraene, "Advertising Node Administrative Tags in OSPF", 445 RFC 7777, DOI 10.17487/RFC7777, March 2016, 446 . 448 12.3. URIs 450 [1] http://tools.ietf.org/html/rfc7777#section-3 452 Authors' Addresses 454 Pushpasis Sarkar (editor) 455 Individual Contributor 457 Email: pushpasis.ietf@gmail.com 459 Hannes Gredler 460 Individual Contributor 462 Email: hannes@gredler.at 463 Shraddha Hegde 464 Juniper Networks, Inc. 465 Electra, Exora Business Park 466 Bangalore, KA 560103 467 India 469 Email: shraddha@juniper.net 471 Stephane Litkowski 472 Orange 474 Email: stephane.litkowski@orange.com 476 Bruno Decraene 477 Orange 479 Email: bruno.decraene@orange.com