IS-IS for IP Internets
Internet Engineering Task Force (IETF)                    P. Sarkar, Ed.
Internet-Draft                                                H. Gredler
Intended status: Standards Track
Request for Comments: 7917                        Individual Contributor
Expires: November 10, 2016
Category: Standards Track                                     H. Gredler
ISSN: 2070-1721                                             RtBrick Inc.
                                                                S. Hegde
                                                  Juniper Networks, Inc.
                                                            S. Litkowski
                                                             B. Decraene
                                                                  Orange
                                                             May 9,
                                                               July 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
   advertise node administrative tags.  This 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 policies, thereby providing a very useful operational
   capability.  Node administrative tags may be used either by either 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]. IS-
   IS.

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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   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.
   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Node Administrative Tags
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.
   2.  Node Administrative Tag Sub-TLV Tags  . . . . . . . . . . . . . . . . . .   3
   3.  Node Administrative Tag (Node-Admin-Tag) Sub-TLV  . . . . . .   3
     3.1.  TLV format Format  . . . . . . . . . . . . . . . . . . . . . . .   4   3
   4.  Elements of Procedure . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Interpretation of Node Administrative Tags  . . . . . . .   5   4
     4.2.  Use of Node Administrative Tags . . . . . . . . . . . . .   5
     4.3.  Processing Node Administrative Tag Changes  . . . . . . .   6   5
   5.  Applications  . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7   6
   7.  Operational Considerations  . . . . . . . . . . . . . . . . .   7
   8.  Manageability Considerations  . . . . . . . . . . . . . . . .   8   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8   7
   10. Contributors  . . . . References  . . . . . . . . . . . . . . . . . . . .   8
   11. Acknowledgments . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
   12.
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . .   8
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     12.2.  Informative References . . . . . . . . . . . . . . . . .   9
     12.3.  URIs   9
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  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.
   The node administrative tag can be used in variety of applications,
   for applications.
   For example:

   (a)   Traffic-engineering applications to provide different path-
         selection
         path-selection criteria.

   (b)   Prefer   Preference for, or prune pruning of, certain paths in Loop Free Loop-Free
         Alternate (LFA) [RFC5286] backup selection via local policies
         as defined in
         [I-D.ietf-rtgwg-lfa-manageability]. [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

   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 part of in the
   specific IS-IS level. 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' "level-wide" or 'domain-wide' "domain-wide" flooding scope.  The
   choice of flooding scope in which a specific node administrative tag
   shall be flooded, flooded is purely a matter of local policy, policy and is defined by
   the needs of the operator's usage. 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 both
   within both the
   'domain-wide' "domain-wide" flooding scope as well as within and one or more 'level-
   wide'
   "level-wide" flooding scope. scopes.

   The format of the Node Administrative Tag (Node-Admin-Tag) sub-TLV
   (see Section 3.1) does not include a topology identifier.  Therefore  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], Format

   [RFC4971] defines the Router CAPABILITY TLV 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/ Type-Length-
   Value (TLV) triplets.

   The new Node Administrative Tag Node-Admin-Tag sub-TLV, like other IS-IS sub-TLVs, is
   formatted as Type/Length/Value (TLV) 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

    Type:   21

 ** RFC Editor** Please replace above suggested value with the IANA-assigned value. (Node-Admin-Tag)

    Length: An 8-bit field that indicates the length of the value Value
            portion in octets and octets; this will be a multiple of 4-octets
         dependent 4 octets,
            depending on the number of tags advertised.

    Value:  A set of multiple 4-octets defining  Defines the node administrative tags. tags (Administrative Tag #1,
            Administrative Tag #2, etc.).  Multiples of 4 octets.

                  Figure 1: IS-IS Node Administrative Tag sub-TLV 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 tag(s) 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
   rules, regulations, and guidelines for using and interpreting a node
   administrative tag which tag; these rules, regulations, and guidelines will
   facilitate interoperable implementations by between vendors.

   Interpretation of tag values is specific to the administrative domain
   of a particular network operator.  Hence  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 Administrative Tag
   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 Administrative Tag Node-Admin-Tag sub-TLV.  The list of Node node
   administrative tags carried in a Node Administrative Tag 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
   registry.
   registration.  Future IS-IS extensions requiring well-known values
   MAY define their own data signalling signaling tailored to the needs of the
   feature or MAY use the capability 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 Administrative Tag Node-Admin-Tag sub-TLVs MAY appear in a Router CAPABILITY TLV
   TLV, or Node Administrative Tag 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- 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 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 Node-Admin-Tag sub-TLV(s) or the addition of new Node Administrative
   Tag
   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 depend will vary, depending on what features working are
   associated with node administrative
   tags and tags; this topic is outside of 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 RFC7777
   section
   Section 3 [1] of [RFC7777] for more details.

   1.  Auto-discovery of Services services

   2.  Policy-based Fast-Re-Route Fast Reroute (FRR)

       (a)   Administrative limitation of LFA scope

       (b)   Optimizing LFA calculations

   3.  Controlling Remote remote LFA tunnel termination

   4.  Mobile back-haul backhaul network service deployment

   5.  Policy-based Explicit Routing 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.  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), 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 networks, because nodes
   included in the IS-IS domain are vulnerable.

7.  Operational Considerations

   Operators can assign a meaning to the node administrative tags which 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
   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 in is the case of with other policy applications, the pruning
   policies can cause the path to be completely removed from the
   forwarding plane, plane and hence have the potential for a more severe
   operational
   impact on operations (e.g., node unreachability due to path removal) by
   comparison
   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 [I-D.ietf-isis-yang-isis-cfg] [YANG-ISIS-CFG], and the routing policy configuration
   model is described in [I-D.ietf-rtgwg-policy-model]. [RTG-POLICY-MODEL].  At the time of writing
   this document, some work to enhance these two
   documents, to other documents so that
   they include the configurations related to node administrative tag related
   configurations, tags is
   either already in progress, 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 the "Sub-TLVs for
   TLV 242" registry.  The following value has been registered.

   Value  Description
   -----  -----------
   21

   ** RFC Editor** Please replace above suggested value with the IANA-
   assigned value.     Node-Admin-Tag

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.

10.1.  Normative References

   [ISO10589]
              International Organization for Standardization,
              "Intermediate system System to Intermediate system System intra-domain
              routeing information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode Network Service network service (ISO 8473), ISO/IEC
              10589:2002, Second Edition.", Nov 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>.

12.2.

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

   [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

   [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
   Individual Contributor
   RtBrick Inc.

   Email: hannes@gredler.at 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