OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
RFC 8687
Document | Type |
RFC - Proposed Standard
(November 2019; No errata)
Updates RFC 5786
Was draft-ietf-ospf-xaf-te (lsr WG)
|
|
---|---|---|---|
Authors | Anton Smirnov , Alvaro Retana , Michael Barnes | ||
Last updated | 2019-11-27 | ||
Replaces | draft-smirnov-ospf-xaf-te | ||
Stream | IETF | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Acee Lindem | ||
Shepherd write-up | Show (last changed 2019-03-21) | ||
IESG | IESG state | RFC 8687 (Proposed Standard) | |
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Martin Vigoureux | ||
Send notices to | Acee Lindem <acee@cisco.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | No IANA Actions |
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 theShow full document text