doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6823.txt b/doc/rfc/rfc6823.txt
new file mode 100644
index 0000000..3a3a4c8
--- /dev/null
+++ b/doc/rfc/rfc6823.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       L. Ginsberg
+Request for Comments: 6823                                    S. Previdi
+Category: Standards Track                                       M. Shand
+ISSN: 2070-1721                                            Cisco Systems
+                                                           December 2010
+
+
+                Advertising Generic Information in IS-IS
+
+Abstract
+
+   This document describes the manner in which generic application
+   information (i.e., information not directly related to the operation
+   of the Intermediate System to Intermediate System (IS-IS) protocol)
+   should be advertised in IS-IS Link State Protocol Data Units (LSPs)
+   and defines guidelines that should be used when flooding such
+   information.
+
+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/rfc6823.
+
+Copyright Notice
+
+   Copyright (c) 2010 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.
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 1]
+
+RFC 6823        Advertising Generic Information in IS-IS   December 2010
+
+
+Table of Contents
+
+   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Encoding Format for GENINFO  . . . . . . . . . . . . . . . . .  3
+     3.1.  GENINFO TLV  . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.2.  Use of Sub-TLVs in GENINFO TLV . . . . . . . . . . . . . .  5
+   4.  GENINFO Flooding Procedures  . . . . . . . . . . . . . . . . .  5
+     4.1.  Leaking Procedures . . . . . . . . . . . . . . . . . . . .  6
+     4.2.  Minimizing Update Confusion  . . . . . . . . . . . . . . .  7
+     4.3.  Interpreting Attribute Information . . . . . . . . . . . .  7
+   5.  Use of a Separate Protocol Instance  . . . . . . . . . . . . .  7
+   6.  Applicability of GENINFO TLV . . . . . . . . . . . . . . . . .  8
+   7.  Standardization Requirements . . . . . . . . . . . . . . . . .  8
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   11. Normative References . . . . . . . . . . . . . . . . . . . . . 10
+
+1.  Overview
+
+   [ISO10589] defines the format of Type-Length-Values (TLVs) that may
+   be sent in IS-IS Protocol Data Units (PDUs).  The first octet of a
+   TLV encodes the "type" or "codepoint" that provides a scope for the
+   information and information format that follows.  The protocol is
+   therefore limited to 256 different codepoints that may be assigned.
+   This number has proved generous as regards the information required
+   for correct operation of the IS-IS protocol.  However, the increasing
+   use of IS-IS Link State Protocol Data Units (LSPs) for advertisement
+   of generic information (GENINFO) not directly related to the
+   operation of the IS-IS protocol places additional demands on the TLV
+   encoding space that have the potential to consume a significant
+   number of TLV codepoints.  This document therefore defines an
+   encoding format for GENINFO that minimizes the consumption of TLV
+   codepoints and also maximizes the flexibility of the formats that can
+   be used to represent GENINFO.
+
+   This document also discusses optimal behavior associated with the
+   advertisement and flooding of LSPs containing GENINFO in order to
+   avoid the advertisement of stale information and minimize the
+   presence of duplicate or conflicting information when advertisements
+   are updated.
+
+   The manner in which the information contained in GENINFO TLVs is
+   exchanged between an instance of the IS-IS protocol and the
+   application that generates or consumes the GENINFO is outside the
+   scope of this specification.
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 2]
+
+RFC 6823        Advertising Generic Information in IS-IS   December 2010
+
+
+   In order to minimize the impact that advertisement of GENINFO may
+   have on the operation of routing, such advertisements MUST occur in
+   the context of a non-zero instance of the IS-IS protocol as defined
+   in [RFC6822] except where the rules for the use of the zero instance
+   set out later in this document are followed.
+
+2.  Conventions Used in This Document
+
+   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 [RFC2119].
+
+3.  Encoding Format for GENINFO
+
+   The encoding format defined below has the following goals regarding
+   the advertisement of GENINFO in IS-IS LSPs:
+
+   o  Minimize the number of IS-IS top level and sub-TLV codepoints
+      required
+
+   o  Minimize the depth of sub-TLV levels required
+
+   In order to support these goals, a new IANA registry has been
+   created.  This registry manages the assignment of IS-IS GENINFO
+   Application Identifiers.  These numbers are unsigned 16-bit numbers
+   ranging in value from 1 to 65535.  Application-specific sub-TLV
+   codepoints are unsigned 8-bit numbers ranging in value from 0 to 255.
+   The assignment of the sub-TLV codepoints is scoped by the Application
+   Identifier.  Management of the application specific sub-TLV
+   codepoints is outside the scope of this document.
+
+3.1.  GENINFO TLV
+
+   The GENINFO TLV supports the advertisement of application-specific
+   information that is not directly related to the operation of the
+   IS-IS protocol.
+
+     Type:   251
+     Length: Number of octets in the value field (3 to 255)
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 3]
+
+RFC 6823        Advertising Generic Information in IS-IS   December 2010
+
+
+     Value:
+
+                                          No. of octets
+                +-----------------------+
+                | Flags                 |     1
+                +-----------------------+
+                | Application ID        |     2
+                +-----------------------+
+                | Application           |
+                | IP Address Info       |     0 to 20
+                +-----------------------+
+                |Additional Application-|     0 to (252 -
+                |  Specific Information |     len of IP Address info)
+                +-----------------------+
+
+
+              Flags
+
+                    0 1 2 3 4 5 6 7
+                   +-+-+-+-+-+-+-+-+
+                   |  Rsvd |V|I|D|S|
+                   +-+-+-+-+-+-+-+-+
+
+   The following bit flags are defined.
+
+      S bit (0x01): If the S bit is set (1), the GENINFO TLV MUST be
+      flooded across the entire routing domain.  If the S bit is not set
+      (0), the TLV MUST NOT be leaked between levels.  This bit MUST NOT
+      be altered during the TLV leaking.
+
+      D bit (0x02): When the GENINFO TLV is leaked from Level-2 to
+      Level-1, the D bit MUST be set.  Otherwise, this bit MUST be
+      clear.  GENINFO TLVs with the D bit set MUST NOT be leaked from
+      Level-1 to Level-2.  This is to prevent TLV looping.
+
+      I bit (0x04): When the I bit is set, the 4-octet IPv4 address
+      associated with the application immediately follows the
+      Application ID.
+
+      V bit (0x08): When the V bit is set, the 16-octet IPv6 address
+      associated with the application immediately follows either the
+      Application ID (if I bit is clear) or the IPv4 address (if I bit
+      is set).
+
+   Application ID
+      An identifier assigned to this application via the IANA registry
+      defined later in this document.
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 4]
+
+RFC 6823        Advertising Generic Information in IS-IS   December 2010
+
+
+   Application IPv4 Address Info
+      The IPv4 address associated with the application.  This is not
+      necessarily an address of a router running the IS-IS protocol.
+
+   Application IPv6 Address Info
+      The IPv6 address associated with the application.  This is not
+      necessarily an address of a router running the IS-IS protocol.
+
+   Additional Application-Specific Information
+      Each application may define additional information to be encoded
+      in a GENINFO TLV following the fixed information.  Definition of
+      such information is beyond the scope of this document.
+
+3.2.  Use of Sub-TLVs in GENINFO TLV
+
+   [RFC5305] introduced the definition and use of sub-TLVs.  One of the
+   advantages of using sub-TLVs rather than fixed encoding of
+   information inside a TLV is to allow for the addition of new
+   information in a backwards compatible manner, i.e., just as with
+   TLVs, implementations are required to ignore sub-TLVs that they do
+   not understand.
+
+   GENINFO TLVs MAY include sub-TLVs in the application specific
+   information as deemed necessary and appropriate for each application.
+   The scope of the codepoints used in such sub-TLVs is defined by the
+   combination of the GENINFO TLV codepoint and the Application ID,
+   i.e., the sub-TLV codepoints are private to the application.  Such
+   sub-TLVs are referred to as APPsub-TLVs.
+
+   Additional levels of APPsub-TLVs may be required when there is
+   variable information that is scoped by a specific APPsub-TLV.  These
+   "nested" sub-TLVs MUST be encoded in the same manner as sub-TLVs,
+   i.e., with a one-octet Type field, a one-octet Length field, and zero
+   or more octets of Value.
+
+4.  GENINFO Flooding Procedures
+
+   This section describes procedures that apply to the propagation of
+   LSPs that contain GENINFO TLVs.  These procedures have been
+   previously discussed in [RFC4971].  This section is intended to serve
+   as a reference specification for future documents that define the use
+   of GENINFO TLV(s) for a specific application -- eliminating the need
+   to repeat the definition of these procedures in the application-
+   specific documents.
+
+   Each GENINFO TLV contains information regarding exactly one
+   application instance as identified by the Application ID in the
+   GENINFO TLV.  When it is necessary to advertise sets of information
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 5]
+
+RFC 6823        Advertising Generic Information in IS-IS   December 2010
+
+
+   with the same Application ID that have different flooding scopes, a
+   router MUST originate a minimum of one GENINFO TLV for each required
+   flooding scope.  GENINFO TLVs that contain information having area/
+   level scope will have the S bit clear.  These TLVs MUST NOT be leaked
+   into another level.  GENINFO TLVs that contain information that has
+   domain scope will have the S bit set.  These TLVs MUST be leaked into
+   other IS-IS levels.  When a TLV is leaked from Level-2 to Level-1,
+   the D bit MUST be set in the Level-1 LSP advertisement.
+
+4.1.  Leaking Procedures
+
+   When leaking GENINFO TLVs downward from Level-2 into Level-1, if the
+   originator of the TLV is a Level-1 router in another area, it is
+   possible that multiple copies of the same TLV may be received from
+   multiple L2 routers in the originating area.  A router performing
+   downward leaking MUST check for such duplication by comparing the
+   contents of the TLVs.  The set of LSPs generated by a router for a
+   given level MUST NOT contain two or more copies of the same GENINFO
+   TLV.
+
+   In order to prevent the use of stale GENINFO information, a system
+   MUST NOT use a GENINFO TLV present in an LSP of a system that is not
+   currently reachable via Level-x paths, where "x" is the level (1 or
+   2) associated with the LSP in which the GENINFO TLV appears.  Note
+   that leaking a GENINFO TLV is one of the uses that is prohibited
+   under these conditions.  The following example illustrates what might
+   occur in the absence of this restriction.
+
+   Example: If Level-1 router A generates a GENINFO TLV and floods it to
+   two L1/L2 routers S and T, they will flood it into the Level-2 sub-
+   domain.  Now suppose the Level-1 area partitions, such that A and S
+   are in one partition and T is in another.  IP routing will still
+   continue to work, but if A now issues a revised version of the
+   GENINFO TLV, or decides to stop advertising it, S will follow suit,
+   but T will continue to advertise the old version until the LSP times
+   out.
+
+   Routers in other areas have to choose whether to trust T's copy of
+   A's GENINFO TLV or S's copy of A's information and they have no
+   reliable way to choose.  By making sure that T stops leaking A's
+   information, this removes the possibility that other routers will use
+   stale information from A.
+
+
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 6]
+
+RFC 6823        Advertising Generic Information in IS-IS   December 2010
+
+
+4.2.  Minimizing Update Confusion
+
+   If an update to a TLV is advertised in an LSP with a different number
+   than the LSP associated with the old advertisement, the possibility
+   exists that other systems can temporarily have either 0 copies of a
+   particular advertisement or 2 copies of a particular advertisement,
+   depending on the order in which new copies of the LSP that had the
+   old advertisement and the LSP that has the new advertisement arrive
+   at other systems.
+
+   Whenever possible, an implementation SHOULD advertise the update to a
+   GENINFO TLV in the LSP with the same number as the advertisement that
+   it replaces.  Where this is not possible, the two affected LSPs
+   SHOULD be flooded as an atomic action.
+
+   Systems that receive an update to an existing GENINFO TLV can
+   minimize the potential disruption associated with the update by
+   employing a hold-down time prior to processing the update so as to
+   allow for the receipt of multiple LSPs associated with the same
+   update prior to beginning processing.
+
+4.3.  Interpreting Attribute Information
+
+   Where a receiving system has two copies of a GENINFO TLV with the
+   same Application ID, attribute information in the two TLVs that does
+   not conflict MUST be considered additive.  When information in the
+   two GENINFO TLVs conflicts, i.e., there are different settings for a
+   given attribute, the procedure used to choose which copy shall be
+   used is undefined.
+
+5.  Use of a Separate Protocol Instance
+
+   The use of the IS-IS flooding mechanism as a means of reliably and
+   efficiently propagating information is understandably attractive.
+   However, it is prudent to remember that the primary purpose of that
+   mechanism is to flood information necessary for the correct operation
+   of the IS-IS protocol.  Flooding of information not directly related
+   to the use of the IS-IS protocol in support of routing degrades the
+   operation of the protocol.  Degradation occurs because the frequency
+   of LSP updates is increased and because the processing of non-routing
+   information in each router consumes resources whose primary
+   responsibility is to efficiently respond to reachability changes in
+   the network.
+
+   Advertisement of GENINFO therefore MUST occur in the context of a
+   non-zero instance of the IS-IS protocol as defined in [RFC6822]
+   except when the use in the zero instance is defined in a Standards
+   Track RFC.
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 7]
+
+RFC 6823        Advertising Generic Information in IS-IS   December 2010
+
+
+   The use of a separate instance of the protocol allows both the
+   flooding and the processing of the non-routing information to be
+   decoupled from the information necessary to support correct routing
+   of data in the network.  The flooding and processing of non-routing
+   information can then be prioritized appropriately.
+
+   Use of a separate protocol instance to advertise GENINFO does not
+   eliminate the need to use prudence in the frequency with which such
+   information is updated.  One of the most egregious oversights is a
+   failure to appropriately dampen changes in the information to be
+   advertised; this can lead to flooding storms.  Documents that specify
+   the use of the mechanisms defined here MUST define the expected rate
+   of change of the information to be advertised.
+
+   If desirable, independent control of the flooding scope for
+   information related to two different applications can be achieved by
+   utilizing separate non-zero protocol instances for each application
+   [RFC6822].
+
+6.  Applicability of GENINFO TLV
+
+   The GENINFO TLV supports the advertisement of application-specific
+   information in IS-IS LSPs that is not directly related to the
+   operation of the IS-IS protocol.  Information advertised in the
+   GENINFO TLV MUST NOT alter basic IS-IS protocol operation including
+   (but not limited to) the establishment of adjacencies, the update
+   process, and the decision process.
+
+7.  Standardization Requirements
+
+   GENINFO is intended to advertise information on behalf of
+   applications whose operations have been defined in a public
+   specification as discussed in [RFC5226].
+
+   The public specification MUST include:
+
+   o  a description of the sub-TLV allocation policy
+
+   o  discussion of security issues
+
+   o  discussion of the rate of change of the information being
+      advertised
+
+   o  justification for the use of GENINFO
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 8]
+
+RFC 6823        Advertising Generic Information in IS-IS   December 2010
+
+
+8.  Security Considerations
+
+   The introduction and use of the new TLV codepoint for GENINFO in and
+   of itself raises no new security issues for IS-IS.
+
+   It is possible that information advertised in a GENINFO TLV by a
+   given application MAY introduce new security issues.  The public
+   specification that defines the use of GENINFO by that application
+   MUST include a discussion of the security issues.  Where appropriate,
+   it is recommended that either [RFC5304] or [RFC5310] be used.
+
+9.  IANA Considerations
+
+   Per this document, IANA has registered a new IS-IS TLV in the "IS-IS
+   TLV Codepoints" registry:
+
+   Type     Description                           IIH   LSP   SNP  Purge
+   ----     ----------------------------------    ---   ---   ---  -----
+   251      Generic Information                    n     y     n     n
+
+   IANA has also created a new registry.  The new registry manages the
+   assignment of Application Identifiers that may be used in the Generic
+   Information TLV.  These identifiers are unsigned 16-bit numbers
+   ranging in value from 1 to 65535.  The value 0 is reserved.  The
+   registration procedure is "Expert Review" as defined in [RFC5226].
+   The expert MUST verify that the public specification that defines the
+   use of GENINFO for the application adequately discusses all points
+   mentioned in Section 7 of this document.
+
+   The following information MUST be specified in the registry:
+
+   o  ID Value (1-65535)
+
+   o  Description
+
+   o  Allowed in Instance zero (Y/N)
+
+   o  Reference Specification
+
+10.  Acknowledgements
+
+   The authors would like to thank JP. Vasseur and David Ward for
+   providing the need to produce this document and Tony Li for making
+   sure it was done with appropriate wisdom and prudence.
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                    [Page 9]
+
+RFC 6823        Advertising Generic Information in IS-IS   December 2010
+
+
+11.  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.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4971]   Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
+               System to Intermediate System (IS-IS) Extensions for
+               Advertising Router Information", RFC 4971, July 2007.
+
+   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+               May 2008.
+
+   [RFC5304]   Li, T. and R. Atkinson, "IS-IS Cryptographic
+               Authentication", RFC 5304, October 2008.
+
+   [RFC5305]   Li, T. and H. Smit, "IS-IS Extensions for Traffic
+               Engineering", RFC 5305, October 2008.
+
+   [RFC5310]   Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
+               and M. Fanto, "IS-IS Generic Cryptographic
+               Authentication", RFC 5310, February 2009.
+
+   [RFC6822]   Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D.
+               Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                   [Page 10]
+
+RFC 6823        Advertising Generic Information in IS-IS   December 2010
+
+
+Authors' Addresses
+
+   Les Ginsberg
+   Cisco Systems
+   510 McCarthy Blvd.
+   Milpitas, CA  95035
+   USA
+
+   EMail: ginsberg@cisco.com
+
+
+   Stefano Previdi
+   Cisco Systems
+   Via Del Serafico 200
+   00142 - Roma
+   Italy
+
+   EMail: sprevidi@cisco.com
+
+
+   Mike Shand
+   Cisco Systems
+   250, Longwater Avenue.
+   Reading, Berks  RG2 6GB
+   UK
+
+   EMail: imc.shand@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al.             Standards Track                   [Page 11]
+