Skip to main content

Advertising Node Administrative Tags in IS-IS
draft-ietf-isis-node-admin-tag-09

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7917.
Authors Pushpasis Sarkar , Hannes Gredler , Shraddha Hegde , Stephane Litkowski , Bruno Decraene
Last updated 2016-04-29 (Latest revision 2016-04-28)
Replaces draft-psarkar-isis-node-admin-tag
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Christian Hopps
Shepherd write-up Show Last changed 2016-02-24
IESG IESG state Became RFC 7917 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Alia Atlas
Send notices to "Christian Hopps" <chopps@chopps.org>
IANA IANA review state Version Changed - Review Needed
draft-ietf-isis-node-admin-tag-09
IS-IS for IP Internets                                    P. Sarkar, Ed.
Internet-Draft                                                H. Gredler
Intended status: Standards Track                  Individual Contributor
Expires: October 30, 2016                                       S. Hegde
                                                  Juniper Networks, Inc.
                                                            S. Litkowski
                                                             B. Decraene
                                                                  Orange
                                                          April 28, 2016

             Advertising Node Administrative Tags in IS-IS
                   draft-ietf-isis-node-admin-tag-09

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 October 30, 2016                [Page 1]
Internet-Draft          Node Admin Tags in IS-IS              April 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 October 30, 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 . . . . . . . . . . . . . . . . . . . .   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  . . . . . . . . . . . . . . . . . . . . . . . .   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 October 30, 2016                [Page 2]
Internet-Draft          Node Admin Tags in IS-IS              April 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 route and path selection.  Route and path selection
   functionality applies to both Traffic Engineering(TE) and non-TE
   applications.  Hence the new TLV for carrying node administrative
   tags is included in Router Capability TLV [I-D.ietf-isis-rfc4971bis].

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 a IS-IS Router Capability
   TLV (TLV-242) [I-D.ietf-isis-rfc4971bis] in the Link State PDUs
   originated by the device.  Router Capablity TLVs
   [I-D.ietf-isis-rfc4971bis] 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.
   Operator MAY choose to advertise a set of node administrative tags
   across levels and another diiferent 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 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 admin
   tags.  Hence, in deployments using multi-topology routing [RFC5120],
   advertising a separate set of node administrative tags for each
   topology SHOULD NOT be supported.

Sarkar, et al.          Expires October 30, 2016                [Page 3]
Internet-Draft          Node Admin Tags in IS-IS              April 2016

3.1.  TLV format

   [I-D.ietf-isis-rfc4971bis], 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: A 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 sequence of multiple 4 octets defining the
         administrative tags.

              Figure 1: IS-IS Node Administrative Tag sub-TLV

   The 'Node Administrative Tag' sub-TLV may be generated more than once
   by an originating router.  This MAY happen if a node carries more
   than 63 node administrative groups and a single sub-TLV does not
   provide sufficient space.  Such occurrence of the 'Node
   Administrative Tag' sub-TLV does not cancel previous announcements,
   but rather is cumulative.

Sarkar, et al.          Expires October 30, 2016                [Page 4]
Internet-Draft          Node Admin Tags in IS-IS              April 2016

4.  Elements of Procedure

4.1.  Interpretation of Node Administrative Tags

   The meaning of Node administrative tags is generally opaque to IS-IS.
   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
   [I-D.ietf-isis-rfc4971bis].

   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
   The Node Administrative Tag 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

Sarkar, et al.          Expires October 30, 2016                [Page 5]
Internet-Draft          Node Admin Tags in IS-IS              April 2016

   or MAY use the capability TLV as defined in
   [I-D.ietf-isis-rfc4971bis].

   Being part of the Router Capability TLV, the node administrative tag
   sub-TLV MUST be reasonably small and stable.  In particular, but not
   limited to, implementations supporting the node administrative tags
   MUST NOT associate advertised tags to changes in the network topology
   (both within and outside the IS-IS domain) or reachability of routes.

4.3.  Processing Node Administrative Tag Changes

   Multiple Node Administrative Tag sub-TLVs MAY appear in a Router
   Capability TLV (TLV-242) 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 an
   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.  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 October 30, 2016                [Page 6]
Internet-Draft          Node Admin Tags in IS-IS              April 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 ISIS
   Prefix tags is also applicable to the usage of node administrative
   tags.

   Defining language for local policies is outside the scope of this
   document.  As in case of other policy applications, the pruning
   policies can cause the path to be completely removed from 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 October 30, 2016                [Page 7]
Internet-Draft          Node Admin Tags in IS-IS              April 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].
   These two documents need to be enhanced to include the node
   administrative tag related configurations.

9.  IANA Considerations

   This specification updates one IS-IS registry: IS-IS Router
   Capabality (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

   [I-D.ietf-isis-rfc4971bis]
              Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
              for Advertising Router Info", draft-ietf-isis-
              rfc4971bis-01 (work in progress), April 2016.

Sarkar, et al.          Expires October 30, 2016                [Page 8]
Internet-Draft          Node Admin Tags in IS-IS              April 2016

   [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.

   [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>.

   [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.,
              Horneffer, M., and P. Sarkar, "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>.

Sarkar, et al.          Expires October 30, 2016                [Page 9]
Internet-Draft          Node Admin Tags in IS-IS              April 2016

   [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>.

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 October 30, 2016               [Page 10]
Internet-Draft          Node Admin Tags in IS-IS              April 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 October 30, 2016               [Page 11]