--- 1/draft-ietf-ospf-xaf-te-05.txt 2019-06-26 04:15:19.656477933 -0700 +++ 2/draft-ietf-ospf-xaf-te-06.txt 2019-06-26 04:15:19.680478540 -0700 @@ -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: June 13, 2019 M. Barnes +Intended status: Standards Track Futurewei Technologies, Inc. +Expires: December 28, 2019 M. Barnes Cisco Systems, Inc. - December 10, 2018 + June 26, 2019 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-05 + draft-ietf-ospf-xaf-te-06 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,158 +32,159 @@ 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 June 13, 2019. + This Internet-Draft will expire on December 28, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 - 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 + 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 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 coupling between the routed protocol and advertised TE signaling - information. In other words, any use of the TE link state database - is limited to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 - [RFC5340]. + 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 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 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 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 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 - different Router IDs for local administrative reasons), there is no - defined way for other routers to discover such misalignment and to - take corrective measures (such as to avoid routing traffic through - affected TE tunnels or alerting the network administrators). The use - of misaligned Router IDs may result in delivering the traffic to the - wrong tail-end router, which could lead to suboptimal routing or even - traffic loops. + identify a node in the corresponding OSPFv2 and OSPFv3 link state + databases (LSDBs). 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 different Router IDs for local administrative reasons), + there is no defined way for other routers to discover such + misalignment and to take corrective measures (such as to avoid + routing traffic through affected TE tunnels or alerting the network + administrators). The use of misaligned Router IDs may result in + delivering the traffic to the wrong tail-end router, which could lead + to suboptimal routing or even traffic loops. This document describes an update to [RFC5786] that allows for the - easy identification of a router's local X-AF IP addresses. Routers - using the Node Attribute TLV [RFC5786] can include non-TE enabled - interface addresses in their OSPF TE advertisements, and also use the - same sub-TLVs to carry X-AF information, facilitating the mapping - described above. + easy identification of a router's local X-AF IP addresses. [RFC5786] + defined the Node IPv4 Local Address and Node IPv6 Local Address sub- + TLVs of the Node Attribute TLV for a router to advertise additional + local IPv4 and IPv6 addresses. However, [RFC5786] did not describe + the advertisement and usage of these sub-TLVs when the address family + of the advertised local address differed from the address family of + the OSPF traffic engineering protocol. + + This document updates [RFC5786] so that a router can also announce + one or more local X-AF addresses using the corresponding Local + Address sub-TLV. Routers using the Node Attribute TLV [RFC5786] can + include non-TE enabled interface addresses in their OSPF TE + advertisements, and also use the same sub-TLVs to carry X-AF + information, facilitating the mapping described above. The method specified in this document can also be used to compute the X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs of a Point-to-Multipoint LSP [RFC4461]. Considerations of using Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside the scope of this document. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Operation - [RFC5786] defined the Node IPv4 Local Address and Node IPv6 Local - Address sub-TLVs of the Node Attribute TLV for a router to advertise - additional local IPv4 and IPv6 addresses. However, [RFC5786] did not - describe the advertisement and usage of these sub-TLVs when the - address family of the advertised local address differed from the - address family of the OSPF traffic engineering protocol. + 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]. - This document updates [RFC5786] so that a router can also announce - 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]. + 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: - 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. 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. + OSPF instance MUST advertise the IP address listed in the Router + Address TLV [RFC3630], [RFC5329] of the X-AF instance maintaining + the TE database. - 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. + OSPF instance 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. + + When TE information is advertised in an OSPF instance both natively + (i.e. as per RFC [RFC3630] or [RFC5329]) and as XAF Node Attribute + TLV it is left to local configuration to determine which TE database + is used to compute routes for the OSPF instance. On Area Border Routers (ABR), each advertised X-AF IP address MUST be advertised into at most one area. If OSPFv2 and OSPFv3 area border routers coincide (i.e., the areas for all OSPFv2 and OSPFv3 interfaces are the same), then the X-AF addresses MUST be advertised into the same area in both instances. This allows other ABRs 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 @@ -257,21 +258,21 @@ 5. Security Considerations This document describes the use of the Local Address sub-TLVs to 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 affect on IP routing. + 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. These threats are already present in other TE-related specifications, and their considerations apply here as well, including [RFC3630] and [RFC5329]. 6. IANA Considerations @@ -288,80 +289,80 @@ 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering + (TE) Extensions to OSPF Version 2", RFC 3630, + DOI 10.17487/RFC3630, September 2003, + . + + [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, + . + [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [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, - . - [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [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. - De kleetlaan 6a + De Kleetlaan 6a Diegem 1831 Belgium Email: as@cisco.com Alvaro Retana - Huawei R&D USA + Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara, CA 95050 USA - Email: alvaro.retana@huawei.com + Email: alvaro.retana@futurewei.com Michael Barnes Cisco Systems, Inc. 510 McCarthy Blvd. Milpitas, CA 95035 USA Email: mjbarnes@cisco.com