doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc8510.txt b/doc/rfc/rfc8510.txt
new file mode 100644
index 0000000..cc869c9
--- /dev/null
+++ b/doc/rfc/rfc8510.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    P. Psenak, Ed.
+Request for Comments: 8510                                 K. Talaulikar
+Category: Standards Track                            Cisco Systems, Inc.
+ISSN: 2070-1721                                            W. Henderickx
+                                                                   Nokia
+                                                       P. Pillay-Esnault
+                                                              Huawei USA
+                                                            January 2019
+
+
+             OSPF Link-Local Signaling (LLS) Extensions for
+                    Local Interface ID Advertisement
+
+Abstract
+
+   Every OSPF interface is assigned an Interface ID that uniquely
+   identifies the interface on the router.  In some cases, it is useful
+   to know the assigned Interface ID on the remote side of the adjacency
+   (Remote Interface ID).
+
+   This document describes the extensions to OSPF link-local signaling
+   (LLS) to advertise the Local Interface ID.
+
+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
+   https://www.rfc-editor.org/info/rfc8510.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Psenak, et al.               Standards Track                    [Page 1]
+
+RFC 8510          OSPF LLS Extensions for Interface ID      January 2019
+
+
+Copyright Notice
+
+   Copyright (c) 2019 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
+   (https://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. Interface ID Exchange Using Link Local TE Opaque LSA .......4
+      1.2. Requirements Language ......................................4
+   2. Interface ID Exchange Using OSPF LLS ............................4
+      2.1. Local Interface ID TLV .....................................5
+   3. Backward Compatibility with RFC 4203 ............................5
+   4. IANA Considerations .............................................6
+   5. Security Considerations .........................................6
+   6. References ......................................................6
+      6.1. Normative References .......................................6
+      6.2. Informative References .....................................7
+   Acknowledgments ....................................................8
+   Authors' Addresses .................................................8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Psenak, et al.               Standards Track                    [Page 2]
+
+RFC 8510          OSPF LLS Extensions for Interface ID      January 2019
+
+
+1.  Introduction
+
+   Every OSPF interface is assigned an Interface ID that uniquely
+   identifies the interface on the router.  [RFC2328] uses this
+   Interface ID in the Router Link State Advertisement (Router-LSA) Link
+   Data for unnumbered links and uses the value of the MIB-II ifIndex
+   [RFC2863].  [RFC4203] refers to these Interface IDs as the Link
+   Local/Remote Identifiers and defines a way to advertise and use them
+   for GMPLS purposes.  [RFC8379] defines a way to advertise Local/
+   Remote Interface IDs in the OSPFv2 Extended Link Opaque LSA.
+
+   There is a known OSPFv2 protocol problem in verifying the
+   bidirectional connectivity with parallel unnumbered links.  If there
+   are two parallel unnumbered links between a pair of routers and each
+   link is only advertised from a single direction, such two
+   unidirectional parallel links could be considered as a valid single
+   bidirectional link during the OSPF route computation on some other
+   router.  If each link is advertised with both its Local and Remote
+   Interface IDs, the advertisement of each link from both sides of
+   adjacency can be verified by cross-checking the Local and Remote
+   Interface IDs of both advertisements.
+
+   From the perspective of the advertising router, the Local Interface
+   ID is a known value.  However, the Remote Interface ID needs to be
+   learned before it can be advertised.  [RFC4203] suggests using the TE
+   Link Local LSA [RFC3630] to communicate the Local Interface ID to
+   neighbors on the link.  Though such a mechanism works, it has some
+   drawbacks.
+
+   This document proposes an extension to OSPF link-local signaling
+   (LLS) [RFC5613] to advertise the Local Interface ID.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Psenak, et al.               Standards Track                    [Page 3]
+
+RFC 8510          OSPF LLS Extensions for Interface ID      January 2019
+
+
+1.1.  Interface ID Exchange Using Link Local TE Opaque LSA
+
+   Usage of the Link Local TE Opaque LSA to propagate the Local
+   Interface ID to the neighbors on the link is described in [RFC4203].
+   This mechanism has the following problems:
+
+   o  LSAs can only be flooded over an existing adjacency that is in
+      Exchange state or greater.  The adjacency state machine progresses
+      independently on each side of the adjacency and, as such, may
+      reach the Full state on one side before the Link Local TE Opaque
+      LSA arrives.  The consequence of this is that the link can be
+      initially advertised without the Remote Interface ID.  Later, when
+      the Link Local TE Opaque LSA arrives, the link must be advertised
+      again but this time with the valid Remote Interface ID.
+      Implementations may choose to wait before advertising the link,
+      but there is no guarantee that the neighbor will ever advertise
+      the Link Local TE Opaque LSA with the Interface ID.  In summary,
+      the existing mechanism does not guarantee that the Remote
+      Interface ID is known at the time the link is advertised.
+
+   o  The Link Local TE Opaque LSA is defined for MPLS Traffic
+      Engineering, but the knowledge of the Remote Interface ID is
+      useful also for cases where MPLS TE is not used.  One example is
+      the mentioned lack of a valid 2-way connectivity check for
+      parallel point-to-point links between OSPF routers.
+
+1.2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Interface ID Exchange Using OSPF LLS
+
+   To address the problems described earlier and to allow the Interface
+   ID exchange to be part of the neighbor discovery process, we propose
+   to extend OSPF link-local signaling to advertise the Local Interface
+   ID in OSPF Hello and Database Description (DD) packets.
+
+
+
+
+
+
+
+
+
+
+
+Psenak, et al.               Standards Track                    [Page 4]
+
+RFC 8510          OSPF LLS Extensions for Interface ID      January 2019
+
+
+2.1.  Local Interface ID TLV
+
+   The Local Interface ID TLV is an LLS TLV.  It has the following
+   format:
+
+    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            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Local Interface ID                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type: 18
+
+      Length: 4 octets
+
+      Local Interface ID: The value of the Local Interface ID.
+
+   Local Interface ID TLV signaling using LLS is applicable to all OSPF
+   interface types other than virtual links.
+
+3.  Backward Compatibility with RFC 4203
+
+   If the Local Interface ID signaling via the Link Local TE Opaque LSA
+   is supported in addition to the new LLS mechanism, implementations
+   that support Local Interface ID signaling using LLS MUST prefer the
+   Local Interface ID value received through LLS over the value received
+   through the Link Local TE Opaque LSA if both are received from the
+   same OSPF router.
+
+   Implementations that support Local Interface ID signaling via the
+   Link Local TE Opaque LSA MAY continue to do so to ensure backward
+   compatibility.  If they also support Local Interface ID signaling
+   using LLS as described in the document, they MUST signal the same
+   Local Interface ID via both mechanisms.
+
+   During the rare conditions in which the Local Interface ID changes, a
+   timing interval may exist where the received values of the Local
+   Interface ID advertised through LLS and the Link Local TE Opaque LSA
+   may differ.  Such a situation is temporary, and received values via
+   both mechanisms should become equal as soon as the next Hello and/or
+   Link Local TE Opaque LSA is regenerated by the originator.
+
+
+
+
+
+
+
+
+Psenak, et al.               Standards Track                    [Page 5]
+
+RFC 8510          OSPF LLS Extensions for Interface ID      January 2019
+
+
+4.  IANA Considerations
+
+   IANA has allocated the following code point in the "Link Local
+   Signalling TLV Identifiers (LLS Types)" subregistry of the "Open
+   Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/
+   Value Identifiers (TLV)" registry.
+
+   18 - Local Interface ID TLV
+
+5.  Security Considerations
+
+   The security considerations for "OSPF Link-Local Signaling" [RFC5613]
+   also apply to the Local Interface ID TLV described in this document.
+   The current usage of a neighbor's Local Interface ID is to
+   disambiguate parallel links between OSPF routers.  Hence,
+   modification of the advertised Local Interface ID TLV may result in
+   the wrong neighbor Interface ID being advertised in the OSPFv2
+   Extended Link Opaque LSA [RFC7684] and could prevent the link from
+   being used.  If authentication is being used in the OSPF routing
+   domain [RFC5709][RFC7474], then the Cryptographic Authentication TLV
+   [RFC5613] SHOULD also be used to protect the contents of the LLS
+   block.
+
+   Receiving a malformed LLS Local Interface ID TLV MUST NOT result in a
+   hard router or OSPF process failure.  The reception of malformed LLS
+   TLVs or sub-TLVs SHOULD be logged, but such logging MUST be rate-
+   limited to prevent denial-of-service (DoS) attacks.
+
+   The Interface ID is assigned by the advertising OSPF router as a
+   locally unique identifier and need not be unique in any broader
+   context; it is not expected to contain any information about the
+   device owner or traffic transiting the device, so there are no
+   privacy concerns associated with its advertisement.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+              DOI 10.17487/RFC2328, April 1998,
+              <https://www.rfc-editor.org/info/rfc2328>.
+
+
+
+
+
+Psenak, et al.               Standards Track                    [Page 6]
+
+RFC 8510          OSPF LLS Extensions for Interface ID      January 2019
+
+
+   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
+              (TE) Extensions to OSPF Version 2", RFC 3630,
+              DOI 10.17487/RFC3630, September 2003,
+              <https://www.rfc-editor.org/info/rfc3630>.
+
+   [RFC4203]  Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
+              Support of Generalized Multi-Protocol Label Switching
+              (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
+              <https://www.rfc-editor.org/info/rfc4203>.
+
+   [RFC5613]  Zinin, A., Roy, A., Nguyen, L., Friedman, B., and
+              D. Yeung, "OSPF Link-Local Signaling", RFC 5613,
+              DOI 10.17487/RFC5613, August 2009,
+              <https://www.rfc-editor.org/info/rfc5613>.
+
+   [RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
+              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
+              Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
+              2015, <https://www.rfc-editor.org/info/rfc7684>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8379]  Hegde, S., Sarkar, P., Gredler, H., Nanduri, M., and
+              L. Jalil, "OSPF Graceful Link Shutdown", RFC 8379,
+              DOI 10.17487/RFC8379, May 2018,
+              <https://www.rfc-editor.org/info/rfc8379>.
+
+6.2.  Informative References
+
+   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+              MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
+              <https://www.rfc-editor.org/info/rfc2863>.
+
+   [RFC5709]  Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
+              Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
+              Authentication", RFC 5709, DOI 10.17487/RFC5709, October
+              2009, <https://www.rfc-editor.org/info/rfc5709>.
+
+   [RFC7474]  Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
+              "Security Extension for OSPFv2 When Using Manual Key
+              Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
+              <https://www.rfc-editor.org/info/rfc7474>.
+
+
+
+
+
+
+
+Psenak, et al.               Standards Track                    [Page 7]
+
+RFC 8510          OSPF LLS Extensions for Interface ID      January 2019
+
+
+Acknowledgments
+
+   Thanks to Tony Przygienda for his extensive review and useful
+   comments.
+
+Authors' Addresses
+
+   Peter Psenak (editor)
+   Cisco Systems, Inc.
+   Apollo Business Center
+   Mlynske nivy 43
+   Bratislava  821 09
+   Slovakia
+
+   Email: ppsenak@cisco.com
+
+
+   Ketan Talaulikar
+   Cisco Systems, Inc.
+   S.No. 154/6, Phase I, Hinjawadi
+   Pune, Maharashtra  411 057
+   India
+
+   Email: ketant@cisco.com
+
+
+   Wim Henderickx
+   Nokia
+   Copernicuslaan 50
+   Antwerp  2018
+   Belgium
+
+   Email: wim.henderickx@nokia.com
+
+
+   Padma Pillay-Esnault
+   Huawei USA
+   2330 Central Expressway
+   Santa Clara,  CA 95050
+   United States of America
+
+   Email: padma@huawei.com
+
+
+
+
+
+
+
+
+
+Psenak, et al.               Standards Track                    [Page 8]
+