summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8687.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8687.txt')
-rw-r--r--doc/rfc/rfc8687.txt384
1 files changed, 384 insertions, 0 deletions
diff --git a/doc/rfc/rfc8687.txt b/doc/rfc/rfc8687.txt
new file mode 100644
index 0000000..3693e2b
--- /dev/null
+++ b/doc/rfc/rfc8687.txt
@@ -0,0 +1,384 @@
+
+
+
+
+Internet Engineering Task Force (IETF) A. Smirnov
+Request for Comments: 8687 Cisco Systems, Inc.
+Updates: 5786 A. Retana
+Category: Standards Track Futurewei Technologies, Inc.
+ISSN: 2070-1721 M. Barnes
+ November 2019
+
+
+ OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
+
+Abstract
+
+ When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6
+ network, the Multiprotocol Label Switching (MPLS) TE Label Switched
+ Path (LSP) infrastructure may be duplicated, even if the destination
+ IPv4 and IPv6 addresses belong to the same remote router. In order
+ to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must
+ be computed over MPLS TE tunnels created using information propagated
+ in another OSPF instance. This issue is solved by advertising cross-
+ address family (X-AF) OSPF TE information.
+
+ This document describes an update to RFC 5786 that allows for the
+ easy identification of a router's local X-AF IP 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 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/rfc8687.
+
+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
+ 2. Requirements Language
+ 3. Operation
+ 4. Backward Compatibility
+ 4.1. Automatically Switched Optical Networks
+ 5. Security Considerations
+ 6. IANA Considerations
+ 7. References
+ 7.1. Normative References
+ 7.2. Informative References
+ Acknowledgements
+ Authors' Addresses
+
+1. Introduction
+
+ TE extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been
+ described to support intra-area TE in IPv4 and IPv6 networks,
+ respectively. In both cases, the TE database provides a tight
+ coupling between the routed protocol and advertised TE signaling
+ information. In other words, any use of the TE database is limited
+ to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340].
+
+ In a dual-stack network, it may be desirable to set up common MPLS TE
+ LSPs to carry traffic destined to addresses from different address
+ families on a router. The use of common LSPs eases potential
+ scalability and management concerns by halving the number of LSPs in
+ the network. Besides, it allows operators to group traffic based on
+ business characteristics, class of service, and/or applications; the
+ operators are not constrained by the network protocol used.
+
+ For example, an LSP created based on MPLS TE information propagated
+ by an OSPFv2 instance can be used to transport both IPv4 and IPv6
+ traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a
+ separate LSP for each address family. Even if, in some cases, the
+ address-family-specific traffic is to be separated, calculation from
+ a common TE database may prove to be operationally beneficial.
+
+ During the SPF calculation on the TE tunnel head-end router, OSPF
+ computes shortcut routes using TE tunnels. A commonly used algorithm
+ for computing shortcuts is defined in [RFC3906]. For that or any
+ similar algorithm to work with a common MPLS TE infrastructure in a
+ dual-stack network, a requirement is to reliably map the X-AF
+ addresses to the corresponding tail-end router. This mapping is a
+ challenge because the Link State Advertisements (LSAs) containing the
+ routing information are carried in one OSPF instance, while the TE
+ calculations may be done using a TE database from a different OSPF
+ instance.
+
+ A simple solution to this problem is to rely on the Router ID to
+ identify a node in the corresponding OSPFv2 and OSPFv3 Link State
+ Databases (LSDBs). This solution would mandate both instances on the
+ same router to be configured with the same Router ID. However,
+ relying on the correctness of configuration puts additional burden
+ and cost on the operation of the network. The network becomes even
+ more difficult to manage if OSPFv2 and OSPFv3 topologies do not match
+ exactly, for example, if area borders are chosen differently in the
+ two protocols. Also, if the routing processes do fall out of sync
+ (e.g., having different Router IDs for local administrative reasons),
+ there is no defined way for other routers to discover such
+ misalignment and to take corrective measures (such as to avoid
+ routing traffic through affected TE tunnels or alerting the network
+ administrators). The use of misaligned Router IDs may result in
+ delivering the traffic to the wrong tail-end router, which could lead
+ to suboptimal routing or even traffic loops.
+
+ This document describes an update to [RFC5786] that allows for the
+ easy identification of a router's local X-AF IP addresses. [RFC5786]
+ defined the Node IPv4 Local Address and Node IPv6 Local Address sub-
+ TLVs of the Node Attribute TLV for a router to advertise additional
+ local IPv4 and IPv6 addresses. However, [RFC5786] did not describe
+ the advertisement and usage of these sub-TLVs when the address family
+ of the advertised local address differed from the address family of
+ the OSPF traffic engineering protocol.
+
+ This document updates [RFC5786] so that a router can also announce
+ one or more local X-AF addresses using the corresponding Local
+ Address sub-TLV. Routers using the Node Attribute TLV [RFC5786] can
+ include non-TE-enabled interface addresses in their OSPF TE
+ advertisements and also use the same sub-TLVs to carry X-AF
+ information, facilitating the mapping described above.
+
+ The method specified in this document can also be used to compute the
+ X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs
+ of a Point-to-Multipoint LSP [RFC4461]. Considerations of using
+ Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside
+ the scope of this document.
+
+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.
+
+3. Operation
+
+ To implement the X-AF routing technique described in this document,
+ OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3
+ will advertise the Node IPv4 Local Address sub-TLV, possibly in
+ addition to advertising other IP addresses as documented by
+ [RFC5786].
+
+ Multiple instances of OSPFv3 are needed if it is used for both IPv4
+ and IPv6 [RFC5838]. The operation in this section is described with
+ OSPFv2 as the protocol used for IPv4; that is the most common case.
+ The case of OSPFv3 being used for IPv4 follows the same procedure as
+ what is indicated for OSPFv2 below.
+
+ On a node that implements X-AF routing, each OSPF instance
+ advertises, using the Node Local Address sub-TLV, all X-AF IPv6 (for
+ OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router
+ that can be used by the Constrained Shortest Path First (CSPF) to
+ calculate MPLS TE LSPs:
+
+ * The OSPF instance MUST advertise the IP address listed in the
+ Router Address TLV [RFC3630] [RFC5329] of the X-AF instance
+ maintaining the TE database.
+
+ * The OSPF instance SHOULD include additional local addresses
+ advertised by the X-AF OSPF instance in its Node Local Address
+ sub-TLVs.
+
+ * An implementation MAY advertise other local X-AF addresses.
+
+ When TE information is advertised in an OSPF instance, both natively
+ (i.e., as per RFC [RFC3630] or [RFC5329]) and as X-AF Node Attribute
+ TLV, it is left to local configuration to determine which TE database
+ is used to compute routes for the OSPF instance.
+
+ On Area Border Routers (ABRs), each advertised X-AF IP address MUST
+ be advertised into, at most, one area. If OSPFv2 and OSPFv3 ABRs
+ coincide (i.e., the areas for all OSPFv2 and OSPFv3 interfaces are
+ the same), then the X-AF addresses MUST be advertised into the same
+ area in both instances. This allows other ABRs connected to the same
+ set of areas to know with which area to associate computed MPLS TE
+ tunnels.
+
+ During the X-AF routing calculation, X-AF IP addresses are used to
+ map locally created LSPs to tail-end routers in the LSDB. The
+ mapping algorithm can be described as:
+
+ Walk the list of all MPLS TE tunnels for which the computing
+ router is a head end. For each MPLS TE tunnel T:
+
+ 1. If T's destination address is from the same address family as
+ the OSPF instance associated with the LSDB, then the
+ extensions defined in this document do not apply.
+
+ 2. Otherwise, it is a X-AF MPLS TE tunnel. Note the tunnel's
+ destination IP address.
+
+ 3. Walk the X-AF IP addresses in the LSDBs of all connected
+ areas. If a matching IP address is found, advertised by
+ router R in area A, then mark the tunnel T as belonging to
+ area A and terminating on tail-end router R. Assign the
+ intra-area SPF cost to reach router R within area A as the IGP
+ cost of tunnel T.
+
+ After completing this calculation, each TE tunnel is associated with
+ an area and tail-end router in terms of the routing LSDB of the
+ computing OSPF instance and has a cost.
+
+ The algorithm described above is to be used only if the Node Local
+ Address sub-TLV includes X-AF information.
+
+ Note that, for clarity of description, the mapping algorithm is
+ specified as a single calculation. Implementations may choose to
+ support equivalent mapping functionality without implementing the
+ algorithm as described.
+
+ As an example, consider a router in a dual-stack network using OSPFv2
+ and OSPFv3 for IPv4 and IPv6 routing, respectively. Suppose the
+ OSPFv2 instance is used to propagate MPLS TE information and the
+ router is configured to accept TE LSPs terminating at local addresses
+ 198.51.100.1 and 198.51.100.2. The router advertises in OSPFv2 the
+ IPv4 address 198.51.100.1 in the Router Address TLV, the additional
+ local IPv4 address 198.51.100.2 in the Node IPv4 Local Address sub-
+ TLV, and other TE TLVs as required by [RFC3630]. If the OSPFv3
+ instance in the network is enabled for X-AF TE routing (that is, to
+ use MPLS TE LSPs computed by OSPFv2 for IPv6 routing), then the
+ OSPFv3 instance of the router will advertise the Node IPv4 Local
+ Address sub-TLV listing the local IPv4 addresses 198.51.100.1 and
+ 198.51.100.2. Other routers in the OSPFv3 network will use this
+ information to reliably identify this router as the egress LSR for
+ MPLS TE LSPs terminating at either 198.51.100.1 or 198.51.100.2.
+
+4. Backward Compatibility
+
+ Only routers that serve as endpoints for one or more TE tunnels MUST
+ be upgraded to support the procedures described herein:
+
+ * Tunnel tail-end routers advertise the Node IPv4 Local Address sub-
+ TLV and/or the Node IPv6 Local Address sub-TLV.
+
+ * Tunnel head-end routers perform the X-AF routing calculation.
+
+ Both the endpoints MUST be upgraded before the tail end starts
+ advertising the X-AF information. Other routers in the network do
+ not need to support X-AF procedures.
+
+4.1. Automatically Switched Optical Networks
+
+ [RFC6827] updates [RFC5786] by defining extensions to be used in an
+ Automatically Switched Optical Network (ASON). The Local TE Router
+ ID sub-TLV is required for determining ASON reachability. The
+ implication is that if the Local TE Router ID sub-TLV is present in
+ the Node Attribute TLV, then the procedures in [RFC6827] apply,
+ regardless of whether any X-AF information is advertised.
+
+5. Security Considerations
+
+ This document describes the use of the Local Address sub-TLVs to
+ provide X-AF information. The advertisement of these sub-TLVs, in
+ any OSPF instance, is not precluded by [RFC5786]. As such, no new
+ security threats are introduced beyond the considerations in OSPFv2
+ [RFC2328], OSPFv3 [RFC5340], and [RFC5786].
+
+ The X-AF information is not used for SPF computation or normal
+ routing, so the mechanism specified here has no effect on IP routing.
+ However, generating incorrect information or tampering with the sub-
+ TLVs may have an effect on traffic engineering computations.
+ Specifically, TE traffic may be delivered to the wrong tail-end
+ router, which could lead to suboptimal routing, traffic loops, or
+ exposing the traffic to attacker inspection or modification. These
+ threats are already present in other TE-related specifications, and
+ their considerations apply here as well, including [RFC3630] and
+ [RFC5329].
+
+6. IANA Considerations
+
+ This document has no IANA actions.
+
+7. References
+
+7.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>.
+
+ [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>.
+
+ [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
+ "Traffic Engineering Extensions to OSPF Version 3",
+ RFC 5329, DOI 10.17487/RFC5329, September 2008,
+ <https://www.rfc-editor.org/info/rfc5329>.
+
+ [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's
+ Local Addresses in OSPF Traffic Engineering (TE)
+ Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010,
+ <https://www.rfc-editor.org/info/rfc5786>.
+
+ [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>.
+
+7.2. Informative References
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+ DOI 10.17487/RFC2328, April 1998,
+ <https://www.rfc-editor.org/info/rfc2328>.
+
+ [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway
+ Protocol (IGP) Routes Over Traffic Engineering Tunnels",
+ RFC 3906, DOI 10.17487/RFC3906, October 2004,
+ <https://www.rfc-editor.org/info/rfc3906>.
+
+ [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
+ Multipoint Traffic-Engineered MPLS Label Switched Paths
+ (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,
+ <https://www.rfc-editor.org/info/rfc4461>.
+
+ [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+ for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
+ <https://www.rfc-editor.org/info/rfc5340>.
+
+ [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
+ R. Aggarwal, "Support of Address Families in OSPFv3",
+ RFC 5838, DOI 10.17487/RFC5838, April 2010,
+ <https://www.rfc-editor.org/info/rfc5838>.
+
+ [RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou,
+ Ed., "Automatically Switched Optical Network (ASON)
+ Routing for OSPFv2 Protocols", RFC 6827,
+ DOI 10.17487/RFC6827, January 2013,
+ <https://www.rfc-editor.org/info/rfc6827>.
+
+Acknowledgements
+
+ The authors would like to thank Peter Psenak and Eric Osborne for
+ early discussions and Acee Lindem for discussing compatibility with
+ ASON extensions. Also, Eric Vyncke, Ben Kaduk, and Roman Danyliw
+ provided useful comments.
+
+ We would also like to thank the authors of RFC 5786 for laying down
+ the foundation for this work.
+
+Authors' Addresses
+
+ Anton Smirnov
+ Cisco Systems, Inc.
+ De Kleetlaan 6a
+ 1831 Diegem
+ Belgium
+
+ Email: as@cisco.com
+
+
+ Alvaro Retana
+ Futurewei Technologies, Inc.
+ 2330 Central Expressway
+ Santa Clara, CA 95050
+ United States of America
+
+ Email: alvaro.retana@futurewei.com
+
+
+ Michael Barnes
+
+ Email: michael_barnes@usa.net