summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7917.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7917.txt')
-rw-r--r--doc/rfc/rfc7917.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc7917.txt b/doc/rfc/rfc7917.txt
new file mode 100644
index 0000000..e0e6989
--- /dev/null
+++ b/doc/rfc/rfc7917.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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-IS
+
+Abstract
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sarkar, et al. Standards Track [Page 1]
+
+RFC 7917 Node Administrative Tags in IS-IS July 2016
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sarkar, et al. Standards Track [Page 2]
+
+RFC 7917 Node Administrative Tags in IS-IS July 2016
+
+
+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
+
+
+
+Sarkar, et al. Standards Track [Page 3]
+
+RFC 7917 Node Administrative Tags in IS-IS July 2016
+
+
+ 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
+
+
+
+
+Sarkar, et al. Standards Track [Page 4]
+
+RFC 7917 Node Administrative Tags in IS-IS July 2016
+
+
+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].
+
+
+
+Sarkar, et al. Standards Track [Page 5]
+
+RFC 7917 Node Administrative Tags in IS-IS July 2016
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sarkar, et al. Standards Track [Page 6]
+
+RFC 7917 Node Administrative Tags in IS-IS July 2016
+
+
+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 routing
+
+6. 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.
+
+
+
+
+
+
+
+Sarkar, et al. Standards Track [Page 7]
+
+RFC 7917 Node Administrative Tags in IS-IS July 2016
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sarkar, et al. Standards Track [Page 8]
+
+RFC 7917 Node Administrative Tags in IS-IS July 2016
+
+
+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>.
+
+
+
+
+Sarkar, et al. Standards Track [Page 9]
+
+RFC 7917 Node Administrative Tags in IS-IS July 2016
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sarkar, et al. Standards Track [Page 10]
+
+RFC 7917 Node Administrative Tags in IS-IS July 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
+
+
+
+
+
+Sarkar, et al. Standards Track [Page 11]
+