OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
draft-ietf-ospf-xaf-te-02
| The information below is for an old version of the document |
| Document |
Type |
|
Active Internet-Draft (lsr WG)
|
|
Last updated |
|
2018-04-19
|
|
Replaces |
|
draft-smirnov-ospf-xaf-te
|
|
Stream |
|
IETF
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
pdf
htmlized
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
I-D Exists
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
LSR A. Smirnov
Internet-Draft Cisco Systems, Inc.
Updates: 5786 (if approved) A. Retana
Intended status: Standards Track Huawei R&D USA
Expires: October 20, 2018 M. Barnes
Cisco Systems, Inc.
April 18, 2018
OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
draft-ietf-ospf-xaf-te-02
Abstract
When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network
the Multiprotocol Label Switching (MPLS) TE Label Switched Paths
(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 is solved by advertising cross-address
family (X-AF) OSPF TE information.
This document describes an update to RFC5786 that allows for the easy
identification of a router's local X-AF IP addresses.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 20, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Smirnov, et al. Expires October 20, 2018 [Page 1]
Internet-Draft OSPF Routing with Cross-AF TE tunnels April 2018
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
TE Extensions to OSPFv2 [RFC3630] and to 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 TE signaling information in
it. In other words, any use of the TE link state 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 and/or applications or class of service, not
constrained by the network protocol which carries it.
For example, an LSP created based on MPLS TE information propagated
by OSPFv2 instance can be defined to carry both IPv4 and IPv6
traffic, instead of having 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, the calculation
from a common database may prove operationally beneficial.
Show full document text