IS-IS for IP Internets P. Sarkar, Ed.
Internet-Draft H. Gredler
Intended status: Standards Track Individual Contributor
Expires: November 10, 2016 S. Hegde
Juniper Networks, Inc.
S. Litkowski
B. Decraene
Orange
May 9, 2016
Advertising Node Administrative Tags in IS-IS
draft-ietf-isis-node-admin-tag-11
Abstract
This document describes an extension to the IS-IS routing protocol to
add an optional capability that allows tagging and grouping of the
nodes in an IS-IS domain. This allows simple management and easy
control over route and path selection, based on local configured
policies. This document describes an extension to the IS-IS protocol
to advertise node administrative tags. The node administrative tags
can be used to express and apply locally defined network policies
which is a very useful operational capability. Node administrative
tags may be used either by IS-IS itself or by other applications
consuming information propagated via IS-IS.
This document describes the protocol extensions to disseminate node
administrative tags in IS-IS protocols.
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].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Sarkar, et al. Expires November 10, 2016 [Page 1]
Internet-Draft Node Admin Tags in IS-IS May 2016
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Node Administrative Tags . . . . . . . . . . . . . . . . . . 3
3. Node Administrative Tag Sub-TLV . . . . . . . . . . . . . . . 3
3.1. TLV format . . . . . . . . . . . . . . . . . . . . . . . 4
4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Operational Considerations . . . . . . . . . . . . . . . . . 7
8. Manageability Considerations . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 9
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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.
Sarkar, et al. Expires November 10, 2016 [Page 2]
Internet-Draft Node Admin Tags in IS-IS May 2016
The node administrative tag can be used in variety of applications,
for example:
(a) Traffic-engineering applications to provide different path-
selection criteria.
(b) Prefer or prune certain paths in Loop Free Alternate (LFA)
backup selection via local policies as defined in
[I-D.ietf-rtgwg-lfa-manageability].
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].
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 the set of groups it is part of in the
specific IS-IS level.
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 Sub-TLV
The new sub-TLV defined 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 needs of the
operator's usage. 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 both within the
'domain-wide' flooding scope as well as within one or more 'level-
wide' flooding scope.
The format of the Node Administrative 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
Sarkar, et al. Expires November 10, 2016 [Page 3]
Internet-Draft Node Admin Tags in IS-IS May 2016
routing [RFC5120], advertising a separate set of node administrative
tags for each topology SHOULD NOT be supported.
3.1. TLV format
[RFC4971], defines 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 Administrative Tag sub-TLV, like other IS-IS sub-TLVs,
is formatted as Type/Length/Value (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 : TBA, Suggested value 21
** RFC Editor** Please replace above suggested value with the IANA-assigned value.
Length: An 8-bit field that indicates the length of the value
portion in octets and will be a multiple of 4-octets
dependent on the number of tags advertised.
Value: A set of multiple 4-octets defining the node
administrative tags.
Figure 1: IS-IS Node Administrative Tag sub-TLV
4. Elements of Procedure
Sarkar, et al. Expires November 10, 2016 [Page 4]
Internet-Draft Node Admin Tags in IS-IS May 2016
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 tag(s) may be
configured to do so without knowing (or even explicitly supporting)
functionality implied by the tag. This section describes general
rules/regulations and guidelines for using and interpreting a node
administrative tag which will facilitate interoperable
implementations by 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 policy to perform a policy action. Each tag carried by the
Node Administrative 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 or another
instance of a Node Administrative Tag sub-TLV. The list of Node
administrative tags carried in a Node Administrative 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
use of node administrative tags or define well-known tag values.
Node administrative tags are for generic use and do not require IANA
registry. Future IS-IS extensions requiring well-known values MAY
define their own data signalling tailored to the needs of the feature
or MAY use the capability TLV as defined in [RFC4971].
Sarkar, et al. Expires November 10, 2016 [Page 5]
Internet-Draft Node Admin Tags in IS-IS May 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 Administrative Tag sub-TLVs MAY appear in a Router
CAPABILITY TLV or Node Administrative 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 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
Administrative Tag sub-TLV(s) or addition of new Node Administrative
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 depend on features working with node administrative
tags and is outside of 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 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 RFC7777
section 3 [1] for more details.
1. Auto-discovery of Services
2. Policy-based Fast-Re-Route (FRR)
Sarkar, et al. Expires November 10, 2016 [Page 6]
Internet-Draft Node Admin Tags in IS-IS May 2016
(a) Administrative limitation of LFA scope
(b) Optimizing LFA calculations
3. Controlling Remote LFA tunnel termination
4. Mobile back-haul network service deployment
5. Policy-based Explicit Routing
6. Security Considerations
Node administrative tags, like link administrative tags [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. Hence this document does not introduce any new
security issues.
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 and nodes
included in the IS-IS domain are vulnerable.
7. Operational Considerations
Operators can assign meaning to the node administrative tags which 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 language for local policies is outside the scope of this
document. As in the case of other policy applications, the pruning
policies can cause the path to be completely removed from the
forwarding plane, and hence have the potential for more severe
operational impact (e.g., node unreachability due to path removal) by
comparison to preference policies that only affect path selection.
Sarkar, et al. Expires November 10, 2016 [Page 7]
Internet-Draft Node Admin Tags in IS-IS May 2016
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 [I-D.ietf-isis-yang-isis-cfg] and the routing policy
configuration model is described in [I-D.ietf-rtgwg-policy-model].
At the time of writing this document, some work to enhance these two
documents, to include the node administrative tag related
configurations, is already in progress, or shall be taken up soon.
9. IANA Considerations
This specification updates one IS-IS registry: IS-IS Router
CAPABILITY (TLV-242) Sub-TLVs Registry
i) Node-Admin-Tag Sub-TLV, Type: TBD, suggested value 21
** RFC Editor** Please replace above suggested value with the IANA-
assigned value.
10. 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 versions of the
draft as well. Finally, many thanks to Li Zhenbin for providing some
valuable use cases.
11. Acknowledgments
Many thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri, and Chris
Bowers for providing useful inputs.
12. References
12.1. Normative References
[ISO10589]
"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/IEC
10589:2002, Second Edition.", Nov 2002.
Sarkar, et al. Expires November 10, 2016 [Page 8]
Internet-Draft Node Admin Tags in IS-IS May 2016
[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>.
12.2. Informative References
[I-D.ietf-isis-yang-isis-cfg]
Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L.
Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf-
isis-yang-isis-cfg-08 (work in progress), March 2016.
[I-D.ietf-rtgwg-lfa-manageability]
Litkowski, S., Decraene, B., Filsfils, C., Raza, K., and
M. Horneffer, "Operational management of Loop Free
Alternates", draft-ietf-rtgwg-lfa-manageability-11 (work
in progress), June 2015.
[I-D.ietf-rtgwg-policy-model]
Shaikh, A., Shakir, R., D'Souza, K., and C. Chase,
"Routing Policy Configuration Model for Service Provider
Networks", draft-ietf-rtgwg-policy-model-01 (work in
progress), April 2016.
[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>.
Sarkar, et al. Expires November 10, 2016 [Page 9]
Internet-Draft Node Admin Tags in IS-IS May 2016
[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>.
12.3. URIs
[1] http://tools.ietf.org/html/rfc7777#section-3
Authors' Addresses
Pushpasis Sarkar (editor)
Individual Contributor
Email: pushpasis.ietf@gmail.com
Hannes Gredler
Individual Contributor
Email: hannes@gredler.at
Sarkar, et al. Expires November 10, 2016 [Page 10]
Internet-Draft Node Admin Tags in IS-IS May 2016
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. Expires November 10, 2016 [Page 11]
