doc: Add RFC documents

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]
+