OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
RFC 8687, “OSPF Routing with Cross-Address Family Traffic Engineering Tunnels”, is a Proposed Standard document published in November 2019 by A. Smirnov, A. Retana, M. Barnes. It updates RFC 5786. The canonical text is published by the RFC Editor.
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.
What “Proposed Standard” means
An entry-level standards-track specification: stable, peer-reviewed and a solid basis for implementation, though it may still evolve before becoming an Internet Standard.
The canonical text of RFC 8687 is hosted at rfc-editor.org. Available in HTML,TXT,PDF,XML.
- RFC 8688 A Session Initiation Protocol Response Code for Rejected Calls
- RFC 8685 Path Computation Element Communication Protocol Extensions for the Hierarchical Path Computation Element Architecture
- RFC 8689 SMTP Require TLS Option
- RFC 8690 Clarification of Segment ID Sub-TLV Length for RFC 8287
- RFC 8683 Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks
- RFC 8691 Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11
- RFC 8692 Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs
- RFC 8694 Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering