--- 1/draft-ietf-ospf-xaf-te-03.txt 2018-10-22 14:15:13.042257310 -0700 +++ 2/draft-ietf-ospf-xaf-te-04.txt 2018-10-22 14:15:13.062257790 -0700 @@ -1,52 +1,52 @@ LSR A. Smirnov Internet-Draft Cisco Systems, Inc. Updates: 5786 (if approved) A. Retana Intended status: Standards Track Huawei R&D USA -Expires: April 6, 2019 M. Barnes +Expires: April 25, 2019 M. Barnes Cisco Systems, Inc. - October 3, 2018 + October 22, 2018 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-03 + draft-ietf-ospf-xaf-te-04 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. + 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- + 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 April 6, 2019. + This Internet-Draft will expire on April 25, 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 @@ -55,228 +55,228 @@ 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.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 to OSPFv3 [RFC5329] have been + 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 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]. + 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]. - In a dual stack network it may be desirable to set up common MPLS TE + 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. + constrained by the network protocol used. 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 + 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, the calculation - from a common database may prove operationally beneficial. + 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 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. 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 the configuration puts additional burden on network - management and adds cost to 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 - drawn differently in the two protocols. Also, if the routing - processes do fall out of sync (having different Router IDs, even if - for local administrative reasons), there is no defined way for other - routers to discover such misalignment and to take any corrective - measures (such as to avoid routing through affected TE tunnels or - issuing warning to network management). 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. + 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 - mentioned above. + described above. - The method described in this document can also be used to compute - X-AF mapping of egress LSR for sub-LSPs of a Point-to-Multipoint LSP - (see [RFC4461]). Considerations of using Point-to-Multipoint MPLS TE - for X-AF traffic forwarding is outside the scope of this - specification. + 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. To solve the problem - outlined in [RFC5786] OSPFv2 would advertise and use only IPv4 - addresses and OSPFv3 would advertise and use only IPv6 addresses. + 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. In other words, to implement the X-AF routing - technique proposed in this document, OSPFv2 will advertise the Node + 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 IP 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 of the X-AF instance maintaining - MPLS TE database plus any additional local addresses advertised by - the X-AF OSPF instance in its Node Local Address sub-TLV. - Implementation MAY advertise other local X-AF addresses. + 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 + 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 carry the required information, it is - left to local configuration to determine which database is used. + 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. On Area Border Routers (ABR), each advertised X-AF IP address MUST be - advertised into at most one area. If OSPFv2 and OSPFv3 area borders - match (i.e. for each interface area number for OSPFv2 and OSPFv3 - instances is numerically equal), 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 MPLS TE tunnels. + 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 - map locally created LSPs to tail-end routers in the LSDB. The - mapping algorithm can be described as: + 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]. 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 an intra-area SPF cost to reach + 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. After completing this calculation, each TE tunnel is associated with an area and tail-end router in terms of the routing LSDB of the - computing OSPF instance and has a metric. + computing OSPF instance and has a cost. + + The algorithm described above is to be used only if Node Local + Address sub-TLV include X-AF information. Note that for clarity of description the mapping algorithm is specified as a single calculation. Actual implementations for the efficiency may choose to support equivalent mapping functionality without implementing the algorithm exactly as it is described. - As an example lets consider a router in dual-stack network running - OSPFv2 and OSPFv3 for IPv4 and IPv6 routing correspondingly. Suppose + As an example, consider a router in a dual-stack network respectively + using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing. Suppose the OSPFv2 instance is used to propagate MPLS TE information and the router is configured to accept TE LSPs terminating at local addresses - 198.51.100.1 and 198.51.100.2. Then the router will advertise into - OSPFv2 instance IPv4 address 198.51.100.1 in the Router Address TLV, - additional local IPv4 address 198.51.100.2 in the Node IPv4 Local - Address sub-TLV, plus other Traffic Engineering TLVs as required by - [RFC3630]. If OSPFv3 instance in the network is enabled for X-AF TE - routing (that is, to use for IPv6 routing MPLS TE LSPs computed by - OSPFv2), then the OSPFv3 instance of the router will advertise the - Node IPv4 Local Address sub-TLV listing local IPv4 addresses - 198.51.100.1 and 198.51.100.2. Other routers in the OSPFv3 network - will use this information to reliably identify this router as egress - LSR for MPLS TE LSPs terminating at either 198.51.100.1 or - 198.51.100.2. + 198.51.100.1 and 198.51.100.2. The router advertises in OSPFv2 the + IPv4 address 198.51.100.1 in the Router Address TLV, the additional + local IPv4 address 198.51.100.2 in the Node IPv4 Local Address sub- + TLV, and other Traffic Engineering TLVs as required by [RFC3630]. If + the OSPFv3 instance in the network is enabled for X-AF TE routing + (that is, to use MPLS TE LSPs computed by OSPFv2 for IPv6 routing), + then the OSPFv3 instance of the router will advertise the Node IPv4 + Local Address sub-TLV listing the local IPv4 addresses 198.51.100.1 + and 198.51.100.2. Other routers in the OSPFv3 network will use this + information to reliably identify this router as the egress LSR for + MPLS TE LSPs terminating at either 198.51.100.1 or 198.51.100.2. 4. Backward Compatibility - Node Attribute TLV and Node Local Address sub-TLVs and their usage - are defined in [RFC5786] and updated by [RFC6827]. Way of using - these TLVs as specified in this document is fully backward compatible - with previous standard documents. - - An implementation processing Node Attribute TLV MUST interpret its - content as follows: - - o If the Node Attribute TLV contains Local TE Router ID sub-TLV then - this Node Attribute TLV MUST be treated as carrying routing - information for ASON (Automatically Switched Optical Network) and - processed as specified in [RFC6827]. - - o Otherwise Node Attribute TLV contains one or more instance(s) of - Node IPv4 Local Address and/or Node IPv6 Local Address sub-TLVs. - Meaning of each Local Address sub-TLV has to be identified - separately. - - * If Node Local Address sub-TLV belongs to the same address - family as instance of OSPF protocol advertising it then address - carried in the sub-TLV MUST be treated as described in - [RFC5786]. - - * Otherwise the address is used for X-AF tunnel tail-end mapping - as defined by this document. - Only routers that serve as endpoints for one or more TE tunnels MUST - be upgraded to support procedures described in this document: + be upgraded to support the procedures described herein: - o Tunnel tailends need to advertise Node IPv4 Local Address and/or - Node IPv6 Local Address sub-TLVs as described in this - specification + o Tunnel tailend routers advertise the Node IPv4 Local Address sub- + TLV and/or the Node IPv6 Local Address sub-TLV. - o Tunnel headends need to perform X-AF routing calculation as - described in this specification + o Tunnel headend routers perform the X-AF routing calculation. 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. + 5. Security Considerations - This document introduces no new security concerns. Security - considerations of using Node Attribute TLV are discussed in - [RFC5786]. + 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. + 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 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.