doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc5786.txt b/doc/rfc/rfc5786.txt
new file mode 100644
index 0000000..64305a1
--- /dev/null
+++ b/doc/rfc/rfc5786.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       R. Aggarwal
+Request for Comments: 5786                                   K. Kompella
+Updates: 3630                                           Juniper Networks
+Category: Standards Track                                     March 2010
+ISSN: 2070-1721
+
+
+                 Advertising a Router's Local Addresses
+              in OSPF Traffic Engineering (TE) Extensions
+
+Abstract
+
+   OSPF Traffic Engineering (TE) extensions are used to advertise TE
+   Link State Advertisements (LSAs) containing information about TE-
+   enabled links.  The only addresses belonging to a router that are
+   advertised in TE LSAs are the local addresses corresponding to TE-
+   enabled links, and the local address corresponding to the Router ID.
+
+   In order to allow other routers in a network to compute Multiprotocol
+   Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE
+   LSPs) to a given router's local addresses, those addresses must also
+   be advertised by OSPF TE.
+
+   This document describes procedures that enhance OSPF TE to advertise
+   a router's local addresses.
+
+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/rfc5786.
+
+
+
+
+
+
+
+
+
+
+
+
+Aggarwal & Kompella          Standards Track                    [Page 1]
+
+RFC 5786         Advertising a Local Router's Addresses       March 2010
+
+
+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.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Motivation .................................................3
+   2. Specification of Requirements ...................................3
+   3. Rejected Potential Solution .....................................4
+   4. Solution ........................................................4
+      4.1. Node Attribute TLV .........................................4
+      4.2. Operation ..................................................5
+   5. Security Considerations .........................................6
+   6. IANA Considerations .............................................6
+   7. Acknowledgements ................................................6
+   8. References ......................................................7
+      8.1. Normative References .......................................7
+      8.2. Informative References .....................................7
+
+
+
+
+
+
+
+
+
+Aggarwal & Kompella          Standards Track                    [Page 2]
+
+RFC 5786         Advertising a Local Router's Addresses       March 2010
+
+
+1.  Introduction
+
+1.1.  Motivation
+
+   In some cases, it is desirable to set up constrained shortest path
+   first (CSPF) computed Multiprotocol Label Switching (MPLS) Traffic
+   Engineered Label Switched Paths (TE LSPs) to local addresses of a
+   router that are not currently advertised in the TE LSAs, i.e.,
+   loopback and non-TE interface addresses.
+
+   For instance, in a network carrying VPN and non-VPN traffic, it is
+   often desirable to use different MPLS TE LSPs for the VPN traffic and
+   the non-VPN traffic.  In this case, one loopback address may be used
+   as the BGP next-hop for VPN traffic while another may be used as the
+   BGP next-hop for non-VPN traffic.  It is also possible that different
+   BGP sessions are used for VPN and non-VPN services.  Hence, two
+   separate MPLS TE LSPs are desirable -- one to each loopback address.
+
+   However, current routers in an OSPF network can only use CSPF to
+   compute MPLS TE LSPs to the router ID or the local addresses of a
+   remote router's TE-enabled links.  This restriction arises because
+   OSPF TE extensions [RFC3630, RFC5329] only advertise the router ID
+   and the local addresses of TE-enabled links of a given router.  Other
+   routers in the network can populate their traffic engineering
+   database (TED) with these local addresses belonging to the
+   advertising router.  However, they cannot populate the TED with the
+   advertising router's other local addresses, i.e., loopback and non-TE
+   interface addresses.  OSPFv2 stub links in the router LSA [RFC2328]
+   provide stub reachability information to the router but are not
+   sufficient to learn all the local addresses of a router.  In
+   particular for a subnetted point-to-point (P2P) interface the stub,
+   link ID is the subnet address.  While for a non-subnetted interface,
+   the stub link ID is the neighbor address.  Intra-prefix LSAs in
+   OSPFv3 [RFC5340] are also not sufficient to learn the local
+   addresses.
+
+   For the above reasons, this document defines an enhancement to OSPF
+   TE extensions to advertise the local addresses of a node.
+
+2.  Specification of Requirements
+
+   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].
+
+
+
+
+
+
+
+Aggarwal & Kompella          Standards Track                    [Page 3]
+
+RFC 5786         Advertising a Local Router's Addresses       March 2010
+
+
+3.  Rejected Potential Solution
+
+   A potential solution would be to advertise a TE link TLV for each
+   local address, possibly with a new link type.  However, this is
+   inefficient since the only meaningful information is the address.
+   Furthermore, this would require implementations to process these TE
+   link TLVs differently from others; for example, the TE metric is
+   normally considered a mandatory sub-TLV, but would have no meaning
+   for a local address.
+
+4.  Solution
+
+   The solution is to advertise the local addresses of a router in a new
+   OSPF TE LSA Node Attribute TLV.  It is anticipated that the Node
+   Attribute TLV will also prove more generally useful.
+
+4.1.  Node Attribute TLV
+
+   The Node Attribute TLV carries the attributes associated with a
+   router.  The TLV type is 5 and the length is variable.  It contains
+   one or more sub-TLVs.  This document defines the following sub-TLVs:
+
+      1.  Node IPv4 Local Address sub-TLV
+      2.  Node IPv6 Local Address sub-TLV
+
+   The Node IPv4 Local Address sub-TLV has a type of 1 and contains one
+   or more local IPv4 addresses.  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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              1                |             Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Prefix Len 1  |          IPv4 Prefix 1                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |Prefix 1 cont. |                                               :
+      +-+-+-+-+-+-+-+-+                                               ~
+      :                               .                               :
+      ~                               .               +-+-+-+-+-+-+-+-+
+      :                               .               | Prefix Len n  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          IPv4 Prefix n                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Each local IPv4 address is encoded as a <Prefix Length, Prefix>
+   tuple.  Prefix Length is encoded in 1 byte.  It is the number of bits
+   in the Address and can be at most 32.  Prefix is an IPv4 address
+   prefix and is encoded in 4 bytes with zero bits as necessary.
+
+
+
+Aggarwal & Kompella          Standards Track                    [Page 4]
+
+RFC 5786         Advertising a Local Router's Addresses       March 2010
+
+
+   The Node IPv4 Local Address sub-TLV length is in octets.  It is the
+   sum of the lengths of all n IPv4 Address encodings in the sub-TLV,
+   where n is the number of local addresses included in the sub-TLV.
+
+   The Node IPv6 Local Address sub-TLV has a type of 2 and contains one
+   or more local IPv6 addresses.  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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              2                |             Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Prefix Len 1  | Prefix 1 Opt. | IPv6 Prefix 1                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   IPv6 Prefix 1 cont.                                         :
+      :                               .                               ~
+      ~                               .
+      :                               .
+      :                               +-+-+-+-+-++-+-+-+-+-++-+-+-+-+-+
+      :                               | Prefix Len n  | Prefix n Opt. |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         IPv6  Prefix n                        :
+      |                                                               :
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
+
+   Each local IPv6 address is encoded using the procedures in [RFC5340].
+   Each IPv6 address MUST be represented by a combination of three
+   fields: PrefixLength, PrefixOptions, and Address Prefix.
+   PrefixLength is the length in bits of the prefix and is an 8-bit
+   field.  PrefixOptions is an 8-bit field describing various
+   capabilities associated with the prefix [RFC5340].  Address Prefix is
+   an encoding of the prefix itself as an even multiple of 32-bit words,
+   padding with zero bits as necessary.  This encoding consumes
+   (PrefixLength + 31) / 32) 32-bit words.
+
+   The Node IPv6 Local Address sub-TLV length is in octets.  It is the
+   sum of the lengths of all n IPv6 Address encodings in the sub-TLV,
+   where n is the number of local addresses included in the sub-TLV.
+
+4.2.  Operation
+
+   A router announces one or more local addresses in the Node Attribute
+   TLV.  The local addresses that can be learned from TE LSAs, i.e.,
+   router address and TE interface addresses SHOULD NOT be advertised in
+   the node local address sub-TLV.  The local addresses advertised will
+   depend on the local configuration of the advertising router.  The
+   default behavior MAY be to advertise all the loopback interface
+   addresses.
+
+
+
+Aggarwal & Kompella          Standards Track                    [Page 5]
+
+RFC 5786         Advertising a Local Router's Addresses       March 2010
+
+
+   The Node Attribute TLV MUST NOT appear in more than one TE LSA
+   originated by a router.  Furthermore, such an LSA MUST NOT include
+   more than one Node Attribute TLV.  A Node Attribute TLV MUST NOT
+   carry more than one Node IPv4 Local Address sub-TLV.  A Node
+   Attribute TLV MUST NOT carry more than one Node IPv6 Local Address
+   sub-TLV.
+
+5.  Security Considerations
+
+   This document does not introduce any further security issues other
+   than those discussed in [RFC3630] and [RFC5329].
+
+6.  IANA Considerations
+
+   IANA has assigned the Node Attribute TLV (value 5) type from the
+   range 3-32767 as specified in [RFC3630], from the top level types in
+   TE LSAs registry maintained by IANA at http://www.iana.org.
+
+   IANA has created and now maintains the registry for the sub-TLVs of
+   the Node Attribute TLV.  Value 1 is reserved for Node IPv4 Local
+   Address sub-TLV and value 2 for Node IPv6 Local Address sub-TLV.
+
+   The guidelines for the assignment of types for sub-TLVs of the Node
+   Attribute TLV are as follows:
+
+      o  Types in the range 3-32767 are to be assigned via Standards
+         Action.
+
+      o  Types in the range 32768-32777 are for experimental use; these
+         will not be registered with IANA, and MUST NOT be mentioned by
+         RFCs.
+
+      o  Types in the range 32778-65535 are not to be assigned at this
+         time.  Before any assignments can be made in this range, there
+         MUST be a Standards Track RFC that specifies IANA
+         Considerations that covers the range being assigned.
+
+7.  Acknowledgements
+
+   We would like to thank Nischal Sheth for his contribution to this
+   work.  We would also like to thank Jean Philippe Vasseur, Acee
+   Lindem, Venkata Naidu, Dimitri Papadimitriou, and Adrian Farrel for
+   their comments.
+
+
+
+
+
+
+
+
+Aggarwal & Kompella          Standards Track                    [Page 6]
+
+RFC 5786         Advertising a Local Router's Addresses       March 2010
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
+              (TE) Extensions to OSPF Version 2", RFC 3630, September
+              2003.
+
+   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+              for IPv6", RFC 5340, July 2008.
+
+8.2. Informative References
+
+   [RFC5329]  Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
+              "Traffic Engineering Extensions to OSPF Version 3", RFC
+              5329, September 2008.
+
+Authors' Addresses
+
+   Rahul Aggarwal
+   Juniper Networks
+   1194 North Mathilda Ave.
+   Sunnyvale, CA 94089
+
+   Phone: +1-408-936-2720
+   EMail: rahul@juniper.net
+
+
+   Kireeti Kompella
+   Juniper Networks
+   1194 North Mathilda Ave.
+   Sunnyvale, CA 94089
+
+   EMail: kireeti@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+Aggarwal & Kompella          Standards Track                    [Page 7]
+