OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
RFC 8687

Document Type RFC - Proposed Standard (November 2019; No errata)
Updates RFC 5786
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