--- 1/draft-ietf-ospf-xaf-te-04.txt 2018-12-10 09:13:16.083668531 -0800 +++ 2/draft-ietf-ospf-xaf-te-05.txt 2018-12-10 09:13:16.107669107 -0800 @@ -1,21 +1,21 @@ LSR A. Smirnov Internet-Draft Cisco Systems, Inc. Updates: 5786 (if approved) A. Retana Intended status: Standards Track Huawei R&D USA -Expires: April 25, 2019 M. Barnes +Expires: June 13, 2019 M. Barnes Cisco Systems, Inc. - October 22, 2018 + December 10, 2018 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04 + draft-ietf-ospf-xaf-te-05 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 issue is solved by advertising cross- @@ -32,21 +32,21 @@ 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 April 25, 2019. + This Internet-Draft will expire on June 13, 2019. Copyright Notice Copyright (c) 2018 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 @@ -54,21 +54,21 @@ 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 + 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 4.1. Automatically Switched Optical Networks . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction @@ -89,26 +89,29 @@ business characteristics and/or applications or class of service, 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 database may prove to be operationally beneficial. - A requirement when creating a common MPLS TE infrastructure is the - ability to reliably map the X-AF family addresses to the - corresponding advertising tail-end router. This mapping is a + 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 LSAs containing the routing information are - carried in one OSPF instance while the TE calculation may be done - using a TE database from a different instance. + 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 databases. This solution would mandate both instances on the same router to be configured with the same Router ID. However, relying on the correctness of configuration puts additional burden and cost on the operation of the network. The network becomes even more difficult to manage if OSPFv2 and OSPFv3 topologies do not match exactly, for example if area borders are chosen differently in the two protocols. Also, if the routing processes do fall out of sync (e.g., having @@ -154,23 +157,23 @@ one or more local X-AF addresses using the corresponding Local Address sub-TLV. In other words, to implement the X-AF routing technique described in this document, OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3 will advertise the Node IPv4 Local Address sub-TLV, possibly in addition to advertising other IP addresses as documented by [RFC5786]. A node that implements X-AF routing SHOULD advertise, in the corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6 addresses local to the router that can be used by Constrained SPF - (CSPF) to calculate MPLS TE LSPs. In general, OSPF SHOULD advertise - the IP address listed in the Router Address TLV [RFC3630] [RFC5329] - of the X-AF instance maintaining the MPLS TE database, plus any + (CSPF) to calculate MPLS TE LSPs. OSPF MUST advertise the IP address + listed in the Router Address TLV [RFC3630] [RFC5329] of the X-AF + instance maintaining the MPLS TE database, and SHOULD include additional local addresses advertised by the X-AF OSPF instance in its Node Local Address sub-TLVs. An implementation MAY advertise other local X-AF addresses. If the Node Attribute TLV carries both the Node IPv4 Local Address sub-TLV and the Node IPv6 Local Address sub-TLV, then the X-AF component MUST be considered for the consolidated calculation of MPLS TE LSPs. Both instances MAY advertise the required information and it is left to local configuration to determine which database is used. @@ -183,24 +186,23 @@ connected to the same set of areas to know with which area to associate computed MPLS TE tunnels. During the X-AF routing calculation, X-AF IP addresses are used to map locally created LSPs to tail-end routers in the Link State Database (LSDB). The mapping algorithm can be described as: Walk the list of all MPLS TE tunnels for which the computing router is a head-end. For each MPLS TE tunnel T: - 1. If T's destination IP address is from the same address family as - the computing OSPF instance, then the tunnel must have been - signaled based on MPLS TE information propagated in the same OSPF - instance. Process the tunnel as per [RFC3630] or [RFC5329]. + 1. If T's destination address is from the same address family as the + OSPF instance associated with the LSDB, then the extensions + defined in this document do not apply. 2. Otherwise it is a X-AF MPLS TE tunnel. Note tunnel's destination IP address. 3. Walk the X-AF IP addresses in the LSDBs of all connected areas. If a matching IP address is found, advertised by router R in area A, then mark the tunnel T as belonging to area A and terminating on tail-end router R. Assign the intra-area SPF cost to reach router R within area A as the IGP cost of tunnel T. @@ -306,20 +308,25 @@ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . + [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway + Protocol (IGP) Routes Over Traffic Engineering Tunnels", + RFC 3906, DOI 10.17487/RFC3906, October 2004, + . + [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, . [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, .