doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc7794.txt b/doc/rfc/rfc7794.txt
new file mode 100644
index 0000000..65e0a1a
--- /dev/null
+++ b/doc/rfc/rfc7794.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                  L. Ginsberg, Ed.
+Request for Comments: 7794                                 Cisco Systems
+Category: Standards Track                                    B. Decraene
+ISSN: 2070-1721                                                   Orange
+                                                              S. Previdi
+                                                           Cisco Systems
+                                                                   X. Xu
+                                                                  Huawei
+                                                             U. Chunduri
+                                                                Ericsson
+                                                              March 2016
+
+
+    IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability
+
+Abstract
+
+   This document introduces new sub-TLVs to support advertisement of
+   IPv4 and IPv6 prefix attribute flags and the source router ID of the
+   router that originated a prefix advertisement.
+
+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 5741.
+
+   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/rfc7794.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 1]
+
+RFC 7794                 IS-IS Prefix Attributes              March 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.  New Sub-TLVs for Extended Reachability TLVs . . . . . . . . .   3
+     2.1.  IPv4/IPv6 Extended Reachability Attribute Flags . . . . .   4
+     2.2.  IPv4/IPv6 Source Router ID  . . . . . . . . . . . . . . .   5
+     2.3.  Advertising Router IDs  . . . . . . . . . . . . . . . . .   6
+   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 2]
+
+RFC 7794                 IS-IS Prefix Attributes              March 2016
+
+
+1.  Introduction
+
+   IS-IS is a link-state routing protocol defined in [ISO10589] and
+   [RFC1195].  Extensions in support of advertising new forms of
+   IPv4/IPv6 prefix reachability are defined in [RFC5305], [RFC5308],
+   and [RFC5120].
+
+   There are existing use cases in which knowing additional attributes
+   of a prefix is useful.
+
+   It is useful to know whether or not an advertised prefix is directly
+   connected to the advertising router.  In the case of Segment Routing
+   as described in [SR], knowing whether or not a prefix is directly
+   connected determines what action should be taken as regards
+   processing of labels associated with an incoming packet.
+
+   It is useful to know what addresses can be used as addresses of the
+   node in support of services (e.g., Remote Loop Free Alternate (RLFA)
+   endpoint).
+
+   Current formats of the Extended Reachability TLVs for both IPv4 and
+   IPv6 are fixed and do not allow the introduction of additional flags
+   without backwards compatibility issues.  Therefore, this document
+   defines a new sub-TLV that supports the advertisement of attribute
+   flags associated with prefix advertisements.
+
+   In cases where multiple node addresses are advertised by a given
+   router, it is also useful to be able to associate all of these
+   addresses with a single Router ID even when prefixes are advertised
+   outside of the area in which they originated.  Therefore, a new sub-
+   TLV is introduced to advertise the Router ID of the originator of a
+   prefix advertisement.
+
+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.  New Sub-TLVs for Extended Reachability TLVs
+
+   The following new sub-TLVs are introduced:
+
+   o  Prefix Attribute Flags
+
+   o  IPv4 Source Router ID
+
+   o  IPv6 Source Router ID
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 3]
+
+RFC 7794                 IS-IS Prefix Attributes              March 2016
+
+
+   All sub-TLVs are applicable to TLVs 135, 235, 236, and 237.
+
+2.1.  IPv4/IPv6 Extended Reachability Attribute Flags
+
+   This sub-TLV supports the advertisement of additional flags
+   associated with a given prefix advertisement.  The behavior of each
+   flag when a prefix advertisement is leaked from one level to another
+   (upwards or downwards) is explicitly defined below.
+
+   All flags are applicable to TLVs 135, 235, 236, and 237, unless
+   otherwise stated.
+
+     Prefix Attribute Flags
+     Type:   4
+     Length: Number of octets of the Value field.
+     Value:
+
+          (Length * 8) bits.
+
+       0 1 2 3 4 5 6 7...
+      +-+-+-+-+-+-+-+-+...
+      |X|R|N|          ...
+      +-+-+-+-+-+-+-+-+...
+
+   Bits are defined/sent starting with Bit 0 defined below.  Additional
+   bit definitions that may be defined in the future SHOULD be assigned
+   in ascending bit order so as to minimize the number of bits that will
+   need to be transmitted.
+
+   Undefined bits MUST be transmitted as 0 and MUST be ignored on
+   receipt.
+
+   Bits that are NOT transmitted MUST be treated as if they are set to 0
+   on receipt.
+
+   X-Flag:  External Prefix Flag (Bit 0)
+      Set if the prefix has been redistributed from another protocol.
+      This includes the case where multiple virtual routers are
+      supported and the source of the redistributed prefix is another
+      IS-IS instance.
+
+      The flag MUST be preserved when leaked between levels.
+
+      In TLVs 236 and 237, this flag SHOULD always be sent as 0 and MUST
+      be ignored on receipt.  This is because there is an existing X
+      flag defined in the fixed format of these TLVs as specified in
+      [RFC5308] and [RFC5120].
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 4]
+
+RFC 7794                 IS-IS Prefix Attributes              March 2016
+
+
+   R-Flag:  Re-advertisement Flag (Bit 1)
+      Set when the prefix has been leaked from one level to another
+      (upwards or downwards).
+
+   N-flag:  Node Flag (Bit 2)
+      Set when the prefix identifies the advertising router, i.e., the
+      prefix is a host prefix advertising a globally reachable address
+      typically associated with a loopback address.
+
+      The advertising router MAY choose to NOT set this flag even when
+      the above conditions are met.
+
+      If the flag is set and the prefix length is NOT a host prefix (/32
+      for IPV4, /128 for IPv6), then the flag MUST be ignored.  The flag
+      MUST be preserved when leaked between levels.
+
+2.2.  IPv4/IPv6 Source Router ID
+
+   When a reachability advertisement is leaked from one level to
+   another, the source of the original advertisement is unknown.  In
+   cases where the advertisement is an identifier for the advertising
+   router (e.g., with the N-flag set in the Prefix Attribute Flags sub-
+   TLV as described in Section 2.1), it may be useful for other routers
+   to know the source of the advertisement.  The sub-TLVs defined below
+   provide that information.
+
+   Note that the Router ID advertised is always the Router ID of the
+   IS-IS instance that originated the advertisement.  This would be true
+   even if the prefix had been learned from another protocol (i.e., with
+   the X-flag set as defined in Section 2.1).
+
+     IPv4 Source Router ID
+     Type:   11
+     Length: 4
+     Value:  IPv4 Router ID of the source of the advertisement
+
+   Inclusion of this TLV is optional and MAY occur in TLVs 135, 235,
+   236, or 237.  When included, the value MUST be identical to the value
+   advertised in the Traffic Engineering router ID (TLV 134) defined in
+   [RFC5305].
+
+   If present the sub-TLV MUST be included when the prefix advertisement
+   is leaked to another level.
+
+     IPv6 Source Router ID
+     Type:   12
+     Length: 16
+     Value: IPv6 Router ID of the source of the advertisement
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 5]
+
+RFC 7794                 IS-IS Prefix Attributes              March 2016
+
+
+   Inclusion of this TLV is optional and MAY occur in TLVs 135, 235,
+   236, or 237.  When included, the value MUST be identical to the value
+   advertised in the IPv6 TE Router ID (TLV 140) defined in [RFC6119].
+
+   If present, the sub-TLV MUST be included when the prefix
+   advertisement is leaked to another level.
+
+2.3.  Advertising Router IDs
+
+   [RFC5305] and [RFC6119] define the advertisement of router IDs for
+   IPv4 and IPv6, respectively.  Although both documents discuss the use
+   of router ID in the context of Traffic Engineering (TE), the
+   advertisement of router IDs is explicitly allowed for purposes other
+   than TE.  The use of router IDs to identify the source of a prefix
+   advertisement as defined in Section 2.2 is one such use case.
+   Therefore, whenever an IPv4 or IPv6 Source Router ID sub-TLV (as
+   defined in Section 2.2) is used, the originating router SHOULD also
+   advertise the corresponding address-family-specific router ID TLV.
+
+3.  IANA Considerations
+
+   This document adds the following new sub-TLVs to the registry of sub-
+   TLVs for TLVs 135, 235, 236, and 237.
+
+      Value: 4
+      Name: Prefix Attribute Flags
+
+      Value: 11
+      Name: IPv4 Source Router ID
+
+      Value: 12
+      Name: IPv6 Source Router ID
+
+   This document also introduces a new registry for bit values in the
+   Prefix Attribute Flags sub-TLV.  The registration policy is Expert
+   Review as defined in [RFC5226].  This registry is part of the "IS-IS
+   TLV Codepoints" registry.  The name of the registry is "Bit Values
+   for Prefix Attribute Flags Sub-TLV".  The defined values are:
+
+        Bit #   Name
+        -----   ------------------------------
+        0       External Prefix Flag (X-flag)
+        1       Re-advertisement Flag (R-flag)
+        2       Node Flag (N-flag)
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 6]
+
+RFC 7794                 IS-IS Prefix Attributes              March 2016
+
+
+4.  Security Considerations
+
+   Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310].
+
+   Advertisement of the additional information defined in this document
+   introduces no new security concerns.
+
+5.  References
+
+5.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/IEC 10589:2002, Second Edition, Nov. 2002.
+
+   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
+              dual environments", RFC 1195, DOI 10.17487/RFC1195,
+              December 1990, <http://www.rfc-editor.org/info/rfc1195>.
+
+   [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>.
+
+   [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>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 7]
+
+RFC 7794                 IS-IS Prefix Attributes              March 2016
+
+
+   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
+              DOI 10.17487/RFC5308, October 2008,
+              <http://www.rfc-editor.org/info/rfc5308>.
+
+   [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>.
+
+   [RFC6119]  Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
+              Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
+              February 2011, <http://www.rfc-editor.org/info/rfc6119>.
+
+5.2.  Informative References
+
+   [SR]       Previdi, S., Ed., Filsfils, C., Bashandy, A., Gredler, H.,
+              Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
+              Extensions for Segment Routing", Work in Progress,
+              draft-ietf-isis-segment-routing-extensions-06, December
+              2015.
+
+Contributors
+
+   The following people gave a substantial contribution to the content
+   of this document:
+
+   Clarence Filsfils
+   Cisco Systems
+
+   Email: cf@cisco.com
+
+
+   Stephane Litkowski
+   Orange Business Service
+
+   Email: stephane.litkowski@orange.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 8]
+
+RFC 7794                 IS-IS Prefix Attributes              March 2016
+
+
+Authors' Addresses
+
+   Les Ginsberg (editor)
+   Cisco Systems
+   510 McCarthy Blvd.
+   Milpitas, CA  95035
+   United States
+
+   Email: ginsberg@cisco.com
+
+
+   Bruno Decraene
+   Orange
+   38 rue du General Leclerc
+   Issy Moulineaux cedex 9  92794
+   France
+
+   Email: bruno.decraene@orange.com
+
+
+   Stefano Previdi
+   Cisco Systems
+   Via Del Serafico 200
+   Rome  0144
+   Italy
+
+   Email: sprevidi@cisco.com
+
+
+   Xiaohu Xu
+   Huawei
+
+   Email: xuxiaohu@huawei.com
+
+
+   Uma Chunduri
+   Ericsson
+
+   Email: uma.chunduri@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 9]
+