idnits 2.17.1 draft-ietf-isis-node-admin-tag-09.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 (April 28, 2016) is 2892 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 453 == Unused Reference: 'RFC5286' is defined on line 432, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-isis-rfc4971bis-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == 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: 1 error (**), 0 flaws (~~), 5 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: October 30, 2016 S. Hegde 6 Juniper Networks, Inc. 7 S. Litkowski 8 B. Decraene 9 Orange 10 April 28, 2016 12 Advertising Node Administrative Tags in IS-IS 13 draft-ietf-isis-node-admin-tag-09 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 October 30, 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 . . . . . . . . . . . . . . . . . . . . 5 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 route and path selection. Route and path selection 109 functionality applies to both Traffic Engineering(TE) and non-TE 110 applications. Hence the new TLV for carrying node administrative 111 tags is included in Router Capability TLV [I-D.ietf-isis-rfc4971bis]. 113 2. Node Administrative Tags 115 An administrative Tag is a 32-bit unsigned integer value that can be 116 used to identify a group of nodes in the IS-IS domain. An IS-IS 117 router SHOULD advertise the set of groups it is part of in the 118 specific IS-IS level. 120 As an example, all edge network devices in a given network may be 121 configured with a certain tag value, whereas all core network devices 122 may be configured with another different tag value. 124 3. Node Administrative Tag Sub-TLV 126 The new sub-TLV defined is carried within a IS-IS Router Capability 127 TLV (TLV-242) [I-D.ietf-isis-rfc4971bis] in the Link State PDUs 128 originated by the device. Router Capablity TLVs 129 [I-D.ietf-isis-rfc4971bis] can have 'level-wide' or 'domain-wide' 130 flooding scope. The choice of flooding scope in which a specific 131 node administrative tag shall be flooded, is purely a matter of local 132 policy, and is defined by the needs of the operator's usage. 133 Operator MAY choose to advertise a set of node administrative tags 134 across levels and another diiferent set of node administrative tags 135 within the specific level. Alternatively, the operator may use the 136 same node administrative tags both within the 'domain-wide' flooding 137 scope as well as within one or more 'level-wide' flooding scope. 139 The format of Node Administrative Tag sub-TLV (see Section 3.1) does 140 not include a topology identifier. Therefore it is not possible to 141 indicate a topology specific context when advertising node admin 142 tags. Hence, in deployments using multi-topology routing [RFC5120], 143 advertising a separate set of node administrative tags for each 144 topology SHOULD NOT be supported. 146 3.1. TLV format 148 [I-D.ietf-isis-rfc4971bis], defines Router Capability TLV which may 149 be used to advertise properties of the originating router. The 150 payload of the Router Capability TLV consists of one or more nested 151 Type/Length/Value (TLV) triplets. 153 The new Node Administrative Tag sub-TLV, like other IS-IS sub-TLVs, 154 is formatted as Type/Length/Value (TLV)triplets. Figure 1 below 155 shows the format of the new sub-TLV. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Type | Length | 161 +- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Administrative Tag #1 | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Administrative Tag #2 | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 // // 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Administrative Tag #N | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Type : TBA, Suggested value 21 173 ** RFC Editor** Please replace above suggested value with the IANA-assigned value. 175 Length: A 8-bit field that indicates the length of the value 176 portion in octets and will be a multiple of 4 octets 177 dependent on the number of tags advertised. 179 Value: A sequence of multiple 4 octets defining the 180 administrative tags. 182 Figure 1: IS-IS Node Administrative Tag sub-TLV 184 The 'Node Administrative Tag' sub-TLV may be generated more than once 185 by an originating router. This MAY happen if a node carries more 186 than 63 node administrative groups and a single sub-TLV does not 187 provide sufficient space. Such occurrence of the 'Node 188 Administrative Tag' sub-TLV does not cancel previous announcements, 189 but rather is cumulative. 191 4. Elements of Procedure 193 4.1. Interpretation of Node Administrative Tags 195 The meaning of Node administrative tags is generally opaque to IS-IS. 196 Router advertising one or more node administrative tag(s) may be 197 configured to do so without knowing (or even explicitly supporting) 198 functionality implied by the tag. This section describes general 199 rules/ regulations and guidelines for using and interpreting a node 200 administrative tag which will facilitate interoperable 201 implementations by vendors. 203 Interpretation of tag values is specific to the administrative domain 204 of a particular network operator. Hence tag values SHOULD NOT be 205 propagated outside the administrative domain to which they apply. 206 The meaning of a node administrative tag is defined by the network 207 local policy and is controlled via configuration. If a receiving 208 node does not understand the tag value, it ignores the specific tag 209 and floods the Router Capability TLV without any change as defined in 210 [I-D.ietf-isis-rfc4971bis]. 212 The semantics of the tag order has no meaning. There is no implied 213 meaning to the ordering of the tags that indicates a certain 214 operation or set of operations that need to be performed based on the 215 ordering. 217 Each tag SHOULD be treated as an independent identifier that MAY be 218 used in policy to perform a policy action. Each tag carried by the 219 The Node Administrative Tag TLVs should be used to indicate a 220 characteristic of a node that is independent of the characteristics 221 indicated by other administrative tags within the same or another 222 instance of a Node Administrative Tag sub-TLV. The list of Node 223 administrative tags carried in a Node Administrative Tag sub-TLV MUST 224 be considered as an unordered list. Whilst policies may be 225 implemented based on the presence of multiple tags (e.g., if tag A 226 AND tag B are present), they MUST NOT be reliant upon the order of 227 the tags (i.e., all policies should be considered commutative 228 operations, such that tag A preceding or following tag B does not 229 change their outcome). 231 4.2. Use of Node Administrative Tags 233 The node administrative tags are not meant to be extended by future 234 IS-IS standards. New IS-IS extensions are not expected to require 235 use of node administrative tags or define well-known tag values. 236 Node administrative tags are for generic use and do not require IANA 237 registry. Future IS-IS extensions requiring well known values MAY 238 define their own data signalling tailored to the needs of the feature 239 or MAY use the capability TLV as defined in 240 [I-D.ietf-isis-rfc4971bis]. 242 Being part of the Router Capability TLV, the node administrative tag 243 sub-TLV MUST be reasonably small and stable. In particular, but not 244 limited to, implementations supporting the node administrative tags 245 MUST NOT associate advertised tags to changes in the network topology 246 (both within and outside the IS-IS domain) or reachability of routes. 248 4.3. Processing Node Administrative Tag Changes 250 Multiple Node Administrative Tag sub-TLVs MAY appear in a Router 251 Capability TLV (TLV-242) or Node Administrative Tag sub-TLVs MAY be 252 contained in different instances of Router Capability TLVs. The Node 253 administrative tags associated with a node that originates tags for 254 the purpose of any computation or processing at a receiving node 255 SHOULD be a superset of node administrative tags from all the TLVs in 256 all the instances of Router Capability TLVs received in the Link- 257 State PDU(s) advertised by the corresponding IS-IS router. When an 258 Router Capability TLV is received that changes the set of node 259 administrative tags applicable to any originating node, a receiving 260 node MUST repeat any computation or processing that makes use of node 261 administrative tags. 263 When there is a change or removal of an administrative affiliation of 264 a node, the node MUST re-originate the Router Capability TLV(s) with 265 the latest set of node administrative tags. On a receiving router, 266 on detecting a change in contents (or removal) of existing Node 267 Administrative Tag sub-TLV(s) or addition of new Node Administrative 268 Tag sub-TLV(s) in any instance of Router Capability TLV(s), 269 implementations MUST take appropriate measures to update their state 270 according to the changed set of node administrative tags. The exact 271 actions needed depend on features working with node administrative 272 tags and is outside of scope of this specification. 274 5. Applications 276 [RFC7777] lists several non-normative examples of how implementations 277 might use Node administrative tags. These examples are given only to 278 demonstrate generic usefulness of the router tagging mechanism. An 279 implementation supporting this specification is not required to 280 implement any of the use cases. Following is a brief list of non- 281 normative use cases listed in [RFC7777]. Please refer to RFC7777 282 section-3 [1] for more details. 284 1. Auto-discovery of Services 286 2. Policy-based Fast-Re-Route(FRR) 287 (a) Administrative limitation of LFA scope 289 (b) Optimizing LFA calculations 291 3. Controlling Remote LFA tunnel termination 293 4. Mobile back-haul network service deployment 295 5. Policy-based Explicit Routing 297 6. Security Considerations 299 Node administrative tags, like link administrative tags [RFC5305], 300 can be used by operators to indicate geographical location or other 301 sensitive information. The information carried in node 302 administrative tags, like link administrative tags, can be leaked to 303 an IGP snooper. Hence this document does not introduce any new 304 security issues. 306 Advertisement of tag values for one administrative domain into 307 another involves the risk of misinterpretation of the tag values (if 308 the two domains have assigned different meanings to the same values), 309 and may have undesirable and unanticipated side effects. 311 Security concerns for IS-IS are already addressed in [ISO10589], 312 [RFC5304], and [RFC5310] and are applicable to the mechanisms 313 described in this document. Extended authentication mechanisms 314 described in [RFC5304] or [RFC5310] SHOULD be used in deployments 315 where attackers have access to the physical networks and nodes 316 included in the IS-IS domain are vulnerable. 318 7. Operational Considerations 320 Operators can assign meaning to the node administrative tags which is 321 local to the operator's administrative domain. The operational use 322 of node administrative tags is analogical to the IS-IS prefix tags 323 [RFC5130] and BGP communities [RFC1997]. Operational discipline and 324 procedures followed in configuring and using BGP communities and ISIS 325 Prefix tags is also applicable to the usage of node administrative 326 tags. 328 Defining language for local policies is outside the scope of this 329 document. As in case of other policy applications, the pruning 330 policies can cause the path to be completely removed from forwarding 331 plane,and hence have the potential for more severe operational impact 332 (e.g., node unreachability due to path removal) by comparison to 333 preference policies that only affect path selection. 335 8. Manageability Considerations 337 Node administrative tags are configured and managed using routing 338 policy enhancements. YANG [RFC6020] is a data modeling language used 339 to specify configuration data models. The IS-IS YANG data model is 340 described in [I-D.ietf-isis-yang-isis-cfg] and the routing policy 341 configuration model is described in [I-D.ietf-rtgwg-policy-model]. 342 These two documents need to be enhanced to include the node 343 administrative tag related configurations. 345 9. IANA Considerations 347 This specification updates one IS-IS registry: IS-IS Router 348 Capabality (TLV-242) Sub-TLVs Registry 350 i) Node-Admin-Tag Sub-TLV, Type: TBD, suggested value 21 352 ** RFC Editor** Please replace above suggested value with the IANA- 353 assigned value. 355 10. Contributors 357 Many many thanks to Ebben Aries and Rafael Rodriguez for their help 358 with reviewing and improving the text of this document. Many thanks 359 to Harish Raguveer for his contributions to initial versions of the 360 draft as well. Finally, many thanks to Li Zhenbin for providing some 361 valuable use cases. 363 11. Acknowledgments 365 Many thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri and Chris 366 Bowers for providing useful inputs. 368 12. References 370 12.1. Normative References 372 [I-D.ietf-isis-rfc4971bis] 373 Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 374 for Advertising Router Info", draft-ietf-isis- 375 rfc4971bis-01 (work in progress), April 2016. 377 [ISO10589] 378 "Intermediate system to Intermediate system intra-domain 379 routeing information exchange protocol for use in 380 conjunction with the protocol for providing the 381 connectionless-mode Network Service (ISO 8473), ISO/IEC 382 10589:2002, Second Edition.", Nov 2002. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, 386 DOI 10.17487/RFC2119, March 1997, 387 . 389 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 390 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 391 2008, . 393 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 394 and M. Fanto, "IS-IS Generic Cryptographic 395 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 396 2009, . 398 12.2. Informative References 400 [I-D.ietf-isis-yang-isis-cfg] 401 Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 402 Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf- 403 isis-yang-isis-cfg-08 (work in progress), March 2016. 405 [I-D.ietf-rtgwg-lfa-manageability] 406 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., 407 Horneffer, M., and P. Sarkar, "Operational management of 408 Loop Free Alternates", draft-ietf-rtgwg-lfa- 409 manageability-11 (work in progress), June 2015. 411 [I-D.ietf-rtgwg-policy-model] 412 Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, 413 "Routing Policy Configuration Model for Service Provider 414 Networks", draft-ietf-rtgwg-policy-model-01 (work in 415 progress), April 2016. 417 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 418 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 419 . 421 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 422 Topology (MT) Routing in Intermediate System to 423 Intermediate Systems (IS-ISs)", RFC 5120, 424 DOI 10.17487/RFC5120, February 2008, 425 . 427 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 428 Control Mechanism in IS-IS Using Administrative Tags", 429 RFC 5130, DOI 10.17487/RFC5130, February 2008, 430 . 432 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 433 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 434 DOI 10.17487/RFC5286, September 2008, 435 . 437 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 438 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 439 2008, . 441 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 442 the Network Configuration Protocol (NETCONF)", RFC 6020, 443 DOI 10.17487/RFC6020, October 2010, 444 . 446 [RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. 447 Decraene, "Advertising Node Administrative Tags in OSPF", 448 RFC 7777, DOI 10.17487/RFC7777, March 2016, 449 . 451 12.3. URIs 453 [1] http://tools.ietf.org/html/rfc7777#section-3 455 Authors' Addresses 457 Pushpasis Sarkar (editor) 458 Individual Contributor 460 Email: pushpasis.ietf@gmail.com 462 Hannes Gredler 463 Individual Contributor 465 Email: hannes@gredler.at 466 Shraddha Hegde 467 Juniper Networks, Inc. 468 Electra, Exora Business Park 469 Bangalore, KA 560103 470 India 472 Email: shraddha@juniper.net 474 Stephane Litkowski 475 Orange 477 Email: stephane.litkowski@orange.com 479 Bruno Decraene 480 Orange 482 Email: bruno.decraene@orange.com