RFC 7917
Advertising Node Administrative Tags in IS-IS
Pages: 11
Proposed Standard
Proposed Standard
Internet Engineering Task Force (IETF) P. Sarkar, Ed. Request for Comments: 7917 Individual Contributor Category: Standards Track H. Gredler ISSN: 2070-1721 RtBrick Inc. S. Hegde Juniper Networks, Inc. S. Litkowski B. Decraene Orange July 2016 Advertising Node Administrative Tags in IS-ISAbstract
This document describes an extension to the IS-IS routing protocol to advertise node administrative tags. This optional capability allows tagging and grouping of the nodes in an IS-IS domain. The node administrative tags can be used to express and apply locally defined network policies, thereby providing a very useful operational capability. Node administrative tags may be used by either IS-IS itself or other applications consuming information propagated via IS- IS. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7917.
Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................3 1.1. Requirements Language ......................................3 2. Node Administrative Tags ........................................3 3. Node Administrative Tag (Node-Admin-Tag) Sub-TLV ................3 3.1. TLV Format .................................................4 4. Elements of Procedure ...........................................5 4.1. Interpretation of Node Administrative Tags .................5 4.2. Use of Node Administrative Tags ............................5 4.3. Processing Node Administrative Tag Changes .................6 5. Applications ....................................................7 6. Security Considerations .........................................7 7. Operational Considerations ......................................8 8. Manageability Considerations ....................................8 9. IANA Considerations .............................................8 10. References .....................................................9 10.1. Normative References ......................................9 10.2. Informative References ....................................9 Acknowledgments ...................................................11 Contributors ......................................................11 Authors' Addresses ................................................11
1. Introduction
It is useful to assign a node administrative tag to a router in the IS-IS domain and use it as an attribute associated with the node. The node administrative tag can be used in variety of applications. For example: (a) Traffic-engineering applications to provide different path-selection criteria. (b) Preference for, or pruning of, certain paths in Loop-Free Alternate (LFA) [RFC5286] backup selection via local policies as defined in [RFC7916]. This document provides mechanisms to advertise node administrative tags in IS-IS for various applications, including (but not limited to) route and path selection. Route and path selection functionality applies to both Traffic Engineering (TE) and non-TE applications. Hence, the new sub-TLV for carrying node administrative tags is included in the Router CAPABILITY TLV [RFC4971].1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].2. Node Administrative Tags
An administrative tag is a 32-bit unsigned integer value that can be used to identify a group of nodes in the IS-IS domain. An IS-IS router should advertise in the specific IS-IS level the set of groups of which it is a part. As an example, all edge network devices in a given network may be configured with a certain tag value, whereas all core network devices may be configured with another, different tag value.3. Node Administrative Tag (Node-Admin-Tag) Sub-TLV
The new sub-TLV defined in this document is carried within an IS-IS Router CAPABILITY TLV (IS-IS TLV type 242) [RFC4971] in the Link State PDUs originated by the device. Router CAPABILITY TLVs [RFC4971] can have "level-wide" or "domain-wide" flooding scope. The choice of flooding scope in which a specific node administrative tag shall be flooded is purely a matter of local policy and is defined by the operator's usage needs. An operator MAY choose to advertise a set of node administrative tags across levels and another different
set of node administrative tags within the specific level. Alternatively, the operator may use the same node administrative tags within both the "domain-wide" flooding scope and one or more "level-wide" flooding scopes. The format of the Node Administrative Tag (Node-Admin-Tag) sub-TLV (see Section 3.1) does not include a topology identifier. Therefore, it is not possible to indicate a topology-specific context when advertising node administrative tags. Hence, in deployments using multi-topology routing [RFC5120], advertising a separate set of node administrative tags for each topology SHOULD NOT be supported.3.1. TLV Format
[RFC4971] defines the Router CAPABILITY TLV, which may be used to advertise properties of the originating router. The payload of the Router CAPABILITY TLV consists of one or more nested Type-Length-Value (TLV) triplets. The new Node-Admin-Tag sub-TLV, like other IS-IS sub-TLVs, is formatted as TLV triplets. Figure 1 below shows the format of the new sub-TLV. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Administrative Tag #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Administrative Tag #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Administrative Tag #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 21 (Node-Admin-Tag) Length: An 8-bit field that indicates the length of the Value portion in octets; this will be a multiple of 4 octets, depending on the number of tags advertised. Value: Defines the node administrative tags (Administrative Tag #1, Administrative Tag #2, etc.). Multiples of 4 octets. Figure 1: IS-IS Node-Admin-Tag Sub-TLV
4. Elements of Procedure
4.1. Interpretation of Node Administrative Tags
The meaning of node administrative tags is generally opaque to IS-IS. A router advertising one or more node administrative tags may be configured to do so without knowing (or even explicitly supporting) the functionality implied by the tag. This section describes general rules, regulations, and guidelines for using and interpreting a node administrative tag; these rules, regulations, and guidelines will facilitate interoperable implementations between vendors. Interpretation of tag values is specific to the administrative domain of a particular network operator. Hence, tag values SHOULD NOT be propagated outside the administrative domain to which they apply. The meaning of a node administrative tag is defined by the network local policy and is controlled via configuration. If a receiving node does not understand the tag value, it ignores the specific tag and floods the Router CAPABILITY TLV without any change, as defined in [RFC4971]. The semantics of the tag order has no meaning. There is no implied meaning to the ordering of the tags that indicates a certain operation or set of operations that need to be performed based on the ordering. Each tag SHOULD be treated as an independent identifier that may be used in a policy to perform a policy action. Each tag carried by the Node-Admin-Tag sub-TLVs should be used to indicate a characteristic of a node that is independent of the characteristics indicated by other administrative tags within the same instance or another instance of a Node-Admin-Tag sub-TLV. The list of node administrative tags carried in a Node-Admin-Tag sub-TLV MUST be considered as an unordered list. Whilst policies may be implemented based on the presence of multiple tags (e.g., if tag A AND tag B are present), they MUST NOT be reliant upon the order of the tags (i.e., all policies should be considered commutative operations, such that tag A preceding or following tag B does not change their outcome).4.2. Use of Node Administrative Tags
The node administrative tags are not meant to be extended by future IS-IS standards. New IS-IS extensions are not expected to require the use of node administrative tags or define well-known tag values. Node administrative tags are for generic use and do not require IANA registration. Future IS-IS extensions requiring well-known values MAY define their own data signaling tailored to the needs of the feature or MAY use the Router CAPABILITY TLV as defined in [RFC4971].
Node administrative tags are expected to be associated with a stable attribute. In particular, node administrative tags MUST NOT be associated with something whose state can oscillate frequently, e.g., the reachability of a specific destination. While no specific limit on the number of node administrative tags that may be advertised has been defined, it is expected that only a modest number of tags will be required in any deployment.4.3. Processing Node Administrative Tag Changes
Multiple Node-Admin-Tag sub-TLVs MAY appear in a Router CAPABILITY TLV, or Node-Admin-Tag sub-TLVs MAY be contained in different instances of Router CAPABILITY TLVs. The node administrative tags associated with a node that originates tags for the purpose of any computation or processing at a receiving node SHOULD be a superset of node administrative tags from all the TLVs in all the instances of Router CAPABILITY TLVs received in the Link State PDU(s) advertised by the corresponding IS-IS router. When a Router CAPABILITY TLV is received that changes the set of node administrative tags applicable to any originating node, a receiving node MUST repeat any computation or processing that makes use of node administrative tags. When there is a change to, or removal of, an administrative affiliation of a node, the node MUST re-originate the Router CAPABILITY TLV(s) with the latest set of node administrative tags. On a receiving router, on detecting a change in contents (or removal) of existing Node-Admin-Tag sub-TLV(s) or the addition of new Node-Admin-Tag sub-TLV(s) in any instance of Router CAPABILITY TLV(s), implementations MUST take appropriate measures to update their state according to the changed set of node administrative tags. The exact actions needed will vary, depending on what features are associated with node administrative tags; this topic is outside the scope of this specification.
5. Applications
[RFC7777] lists several non-normative examples of how implementations might use node administrative tags. These examples are given only to demonstrate the generic usefulness of the router tagging mechanism. An implementation supporting this specification is not required to implement any of the use cases. The following is a brief list of non-normative use cases listed in [RFC7777]. Please refer to Section 3 of [RFC7777] for more details. 1. Auto-discovery of services 2. Policy-based Fast Reroute (FRR) (a) Administrative limitation of LFA scope (b) Optimizing LFA calculations 3. Controlling remote LFA tunnel termination 4. Mobile backhaul network service deployment 5. Policy-based explicit routing6. Security Considerations
This document does not introduce any new security issues. Node administrative tags, like link administrative tags (a.k.a. administrative groups) [RFC5305], can be used by operators to indicate geographical location or other sensitive information. The information carried in node administrative tags, like link administrative tags, can be leaked to an IGP snooper. Advertisement of tag values for one administrative domain into another involves the risk of misinterpretation of the tag values (if the two domains have assigned different meanings to the same values) and may have undesirable and unanticipated side effects. Security concerns for IS-IS are already addressed in [ISO10589], [RFC5304], and [RFC5310] and are applicable to the mechanisms described in this document. Extended authentication mechanisms described in [RFC5304] or [RFC5310] SHOULD be used in deployments where attackers have access to the physical networks, because nodes included in the IS-IS domain are vulnerable.
7. Operational Considerations
Operators can assign a meaning to the node administrative tags that is local to the operator's administrative domain. The operational use of node administrative tags is analogical to the IS-IS prefix tags [RFC5130] and BGP communities [RFC1997]. Operational discipline and procedures followed in configuring and using BGP communities and IS-IS prefix tags are also applicable to the usage of node administrative tags. Defining a language for local policies is outside the scope of this document. As is the case with other policy applications, the pruning policies can cause the path to be completely removed from the forwarding plane and hence have the potential for a more severe impact on operations (e.g., node unreachability due to path removal) as compared to preference policies that only affect path selection.8. Manageability Considerations
Node administrative tags are configured and managed using routing policy enhancements. YANG [RFC6020] is a data modeling language used to specify configuration data models. The IS-IS YANG data model is described in [YANG-ISIS-CFG], and the routing policy configuration model is described in [RTG-POLICY-MODEL]. At the time of writing this document, some work to enhance these two other documents so that they include configurations related to node administrative tags is either already in progress or shall be taken up soon.9. IANA Considerations
This specification updates one IS-IS registry: the "Sub-TLVs for TLV 242" registry. The following value has been registered. Value Description ----- ----------- 21 Node-Admin-Tag
10. References
10.1. Normative References
[ISO10589] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO Standard 10589, 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, DOI 10.17487/RFC4971, July 2007, <http://www.rfc-editor.org/info/rfc4971>. [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>. [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.10.2. Informative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <http://www.rfc-editor.org/info/rfc5120>. [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, DOI 10.17487/RFC5130, February 2008, <http://www.rfc-editor.org/info/rfc5130>.
[RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>. [RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. Decraene, "Advertising Node Administrative Tags in OSPF", RFC 7777, DOI 10.17487/RFC7777, March 2016, <http://www.rfc-editor.org/info/rfc7777>. [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., Horneffer, M., and P. Sarkar, "Operational Management of Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, July 2016, <http://www.rfc-editor.org/info/rfc7916>. [RTG-POLICY-MODEL] Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, "Routing Policy Configuration Model for Service Provider Networks", Work in Progress, draft-ietf-rtgwg-policy-model-01, April 2016. [YANG-ISIS-CFG] Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. Lhotka, "YANG Data Model for IS-IS protocol", Work in Progress, draft-ietf-isis-yang-isis-cfg-08, March 2016.
Acknowledgments
Many thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri, and Chris Bowers for providing useful inputs.Contributors
Many many thanks to Ebben Aries and Rafael Rodriguez for their help with reviewing and improving the text of this document. Many thanks to Harish Raguveer for his contributions to initial draft versions of the document as well. Finally, many thanks to Zhenbin Li for providing some valuable use cases.Authors' Addresses
Pushpasis Sarkar (editor) Individual Contributor Email: pushpasis.ietf@gmail.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com Shraddha Hegde Juniper Networks, Inc. Electra, Exora Business Park Bangalore, KA 560103 India Email: shraddha@juniper.net Stephane Litkowski Orange Email: stephane.litkowski@orange.com Bruno Decraene Orange Email: bruno.decraene@orange.com