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)
|
|
|---|---|---|---|
| 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 the
Show full document text