--- 1/draft-ietf-ospf-xaf-te-06.txt 2019-08-16 08:13:11.567974017 -0700 +++ 2/draft-ietf-ospf-xaf-te-07.txt 2019-08-16 08:13:11.587974525 -0700 @@ -1,21 +1,20 @@ LSR A. Smirnov Internet-Draft Cisco Systems, Inc. Updates: 5786 (if approved) A. Retana Intended status: Standards Track Futurewei Technologies, Inc. -Expires: December 28, 2019 M. Barnes - Cisco Systems, Inc. - June 26, 2019 +Expires: February 16, 2020 M. Barnes + August 15, 2019 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-06 + draft-ietf-ospf-xaf-te-07 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 +31,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 December 28, 2019. + This Internet-Draft will expire on February 16, 2020. 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 @@ -58,21 +57,21 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 4.1. Automatically Switched Optical Networks . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 @@ -153,20 +152,26 @@ capitals, as shown here. 3. Operation 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]. + Multiple instances of OSPFv3 are needed if it is used for both IPv4 + and IPv6 [RFC5838]. The operation in this section is described with + OSPFv2 as the protocol used for IPv4; that is the most common case. + The case of OSPFv3 being used for IPv4 follows the same procedure as + what is indicated for OSPFv2 below. + On a node that implements X-AF routing, each OSPF instance advertises, using the Node Local Address sub-TLV, all X-AF IPv6 (for OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router that can be used by Constrained SPF (CSPF) to calculate MPLS TE LSPs: OSPF instance MUST advertise the IP address listed in the Router Address TLV [RFC3630], [RFC5329] of the X-AF instance maintaining the TE database. OSPF instance SHOULD include additional local addresses advertised @@ -238,21 +243,23 @@ 4. Backward Compatibility Only routers that serve as endpoints for one or more TE tunnels MUST be upgraded to support the procedures described herein: o Tunnel tailend routers advertise the Node IPv4 Local Address sub- TLV and/or the Node IPv6 Local Address sub-TLV. o Tunnel headend routers perform the X-AF routing calculation. - Other routers in the network do not need to support X-AF procedures. + Both the endpoints MUST be upgraded before the tailend starts + advertising the X-AF information. Other routers in the network do + not need to support X-AF procedures. 4.1. Automatically Switched Optical Networks [RFC6827] updates [RFC5786] by defining extensions to be used in an Automatically Switched Optical Network (ASON). The Local TE Router ID Sub-TLV is required for determining ASON reachability. The implication is that if the Local TE Router ID Sub-TLV is present in the Node Attribute TLV, then the procedures in [RFC6827] apply, regardless of whether any X-AF information is advertised. @@ -262,34 +269,36 @@ provide X-AF information. The advertisement of these sub-TLVs, in any OSPF instance, is not precluded by [RFC5786]. As such, no new security threats are introduced beyond the considerations in OSPFv2 [RFC2328], OSPFv3 [RFC5340], and [RFC5786]. The X-AF information is not used for SPF computation or normal routing, so the mechanism specified here has no effect on IP routing. However, generating incorrect information, or tampering with the sub- TLVs may have an effect on traffic engineering computations. Specifically, TE traffic may be delivered to the wrong tail-end - router, which could lead to suboptimal routing or even traffic loops. + router, which could lead to suboptimal routing, traffic loops, or + even expose the traffic to attacker inspection or modification. These threats are already present in other TE-related specifications, and their considerations apply here as well, including [RFC3630] and [RFC5329]. 6. IANA Considerations This document has no IANA actions. 7. Acknowledgements The authors would like to thank Peter Psenak and Eric Osborne for early discussions and Acee Lindem for discussing compatibility with - ASON extensions. + ASON extensions. Also, Eric Vyncke, Ben Kaduk and Roman Danyliw + provided useful comments. We would also like to thank the authors of RFC5786 for laying down the foundation for this work. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, @@ -328,20 +337,25 @@ [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, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . + [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and + R. Aggarwal, "Support of Address Families in OSPFv3", + RFC 5838, DOI 10.17487/RFC5838, April 2010, + . + [RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, Ed., "Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols", RFC 6827, DOI 10.17487/RFC6827, January 2013, . Authors' Addresses Anton Smirnov Cisco Systems, Inc. @@ -353,16 +367,12 @@ Alvaro Retana Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara, CA 95050 USA Email: alvaro.retana@futurewei.com Michael Barnes - Cisco Systems, Inc. - 510 McCarthy Blvd. - Milpitas, CA 95035 - USA - Email: mjbarnes@cisco.com + Email: michael_barnes@usa.net