idnits 2.17.1 draft-ietf-ospf-xaf-te-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5786, but the abstract doesn't seem to directly say this. It does mention RFC5786 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5786, updated by this document, for RFC5378 checks: 2004-04-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 26, 2019) is 1764 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR A. Smirnov 3 Internet-Draft Cisco Systems, Inc. 4 Updates: 5786 (if approved) A. Retana 5 Intended status: Standards Track Futurewei Technologies, Inc. 6 Expires: December 28, 2019 M. Barnes 7 Cisco Systems, Inc. 8 June 26, 2019 10 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels 11 draft-ietf-ospf-xaf-te-06 13 Abstract 15 When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 16 network, the Multiprotocol Label Switching (MPLS) TE Label Switched 17 Paths (LSP) infrastructure may be duplicated, even if the destination 18 IPv4 and IPv6 addresses belong to the same remote router. In order 19 to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must 20 be computed over MPLS TE tunnels created using information propagated 21 in another OSPF instance. This issue is solved by advertising cross- 22 address family (X-AF) OSPF TE information. 24 This document describes an update to RFC5786 that allows for the easy 25 identification of a router's local X-AF IP addresses. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 28, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 65 4.1. Automatically Switched Optical Networks . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 TE Extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been 77 described to support intra-area TE in IPv4 and IPv6 networks, 78 respectively. In both cases, the TE database provides a tight 79 coupling between the routed protocol and advertised TE signaling 80 information. In other words, any use of the TE database is limited 81 to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340]. 83 In a dual stack network, it may be desirable to set up common MPLS TE 84 LSPs to carry traffic destined to addresses from different address 85 families on a router. The use of common LSPs eases potential 86 scalability and management concerns by halving the number of LSPs in 87 the network. Besides, it allows operators to group traffic based on 88 business characteristics and/or applications or class of service, not 89 constrained by the network protocol used. 91 For example, an LSP created based on MPLS TE information propagated 92 by an OSPFv2 instance can be used to transport both IPv4 and IPv6 93 traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a 94 separate LSP for each address family. Even if in some cases the 95 address family-specific traffic is to be separated, calculation from 96 a common TE database may prove to be operationally beneficial. 98 During the SPF calculation on the TE tunnel head-end router, OSPF 99 computes shortcut routes using TE tunnels. A commonly used algorithm 100 for computing shortcuts is defined in [RFC3906]. For that, or any 101 similar, algorithm to work with a common MPLS TE infrastructure in a 102 dual-stack network, a requirement is to reliably map the X-AF 103 addresses to the corresponding tail-end router. This mapping is a 104 challenge because the LSAs containing the routing information are 105 carried in one OSPF instance while the TE calculations may be done 106 using a TE database from a different OSPF instance. 108 A simple solution to this problem is to rely on the Router ID to 109 identify a node in the corresponding OSPFv2 and OSPFv3 link state 110 databases (LSDBs). This solution would mandate both instances on the 111 same router to be configured with the same Router ID. However, 112 relying on the correctness of configuration puts additional burden 113 and cost on the operation of the network. The network becomes even 114 more difficult to manage if OSPFv2 and OSPFv3 topologies do not match 115 exactly, for example if area borders are chosen differently in the 116 two protocols. Also, if the routing processes do fall out of sync 117 (e.g., having different Router IDs for local administrative reasons), 118 there is no defined way for other routers to discover such 119 misalignment and to take corrective measures (such as to avoid 120 routing traffic through affected TE tunnels or alerting the network 121 administrators). The use of misaligned Router IDs may result in 122 delivering the traffic to the wrong tail-end router, which could lead 123 to suboptimal routing or even traffic loops. 125 This document describes an update to [RFC5786] that allows for the 126 easy identification of a router's local X-AF IP addresses. [RFC5786] 127 defined the Node IPv4 Local Address and Node IPv6 Local Address sub- 128 TLVs of the Node Attribute TLV for a router to advertise additional 129 local IPv4 and IPv6 addresses. However, [RFC5786] did not describe 130 the advertisement and usage of these sub-TLVs when the address family 131 of the advertised local address differed from the address family of 132 the OSPF traffic engineering protocol. 134 This document updates [RFC5786] so that a router can also announce 135 one or more local X-AF addresses using the corresponding Local 136 Address sub-TLV. Routers using the Node Attribute TLV [RFC5786] can 137 include non-TE enabled interface addresses in their OSPF TE 138 advertisements, and also use the same sub-TLVs to carry X-AF 139 information, facilitating the mapping described above. 141 The method specified in this document can also be used to compute the 142 X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs 143 of a Point-to-Multipoint LSP [RFC4461]. Considerations of using 144 Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside 145 the scope of this document. 147 2. Requirements Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 3. Operation 157 To implement the X-AF routing technique described in this document, 158 OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3 159 will advertise the Node IPv4 Local Address sub-TLV, possibly in 160 addition to advertising other IP addresses as documented by 161 [RFC5786]. 163 On a node that implements X-AF routing, each OSPF instance 164 advertises, using the Node Local Address sub-TLV, all X-AF IPv6 (for 165 OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router 166 that can be used by Constrained SPF (CSPF) to calculate MPLS TE LSPs: 168 OSPF instance MUST advertise the IP address listed in the Router 169 Address TLV [RFC3630], [RFC5329] of the X-AF instance maintaining 170 the TE database. 172 OSPF instance SHOULD include additional local addresses advertised 173 by the X-AF OSPF instance in its Node Local Address sub-TLVs. 175 An implementation MAY advertise other local X-AF addresses. 177 When TE information is advertised in an OSPF instance both natively 178 (i.e. as per RFC [RFC3630] or [RFC5329]) and as XAF Node Attribute 179 TLV it is left to local configuration to determine which TE database 180 is used to compute routes for the OSPF instance. 182 On Area Border Routers (ABR), each advertised X-AF IP address MUST be 183 advertised into at most one area. If OSPFv2 and OSPFv3 area border 184 routers coincide (i.e., the areas for all OSPFv2 and OSPFv3 185 interfaces are the same), then the X-AF addresses MUST be advertised 186 into the same area in both instances. This allows other ABRs 187 connected to the same set of areas to know with which area to 188 associate computed MPLS TE tunnels. 190 During the X-AF routing calculation, X-AF IP addresses are used to 191 map locally created LSPs to tail-end routers in the Link State 192 Database (LSDB). The mapping algorithm can be described as: 194 Walk the list of all MPLS TE tunnels for which the computing 195 router is a head-end. For each MPLS TE tunnel T: 197 1. If T's destination address is from the same address family as the 198 OSPF instance associated with the LSDB, then the extensions 199 defined in this document do not apply. 201 2. Otherwise it is a X-AF MPLS TE tunnel. Note tunnel's destination 202 IP address. 204 3. Walk the X-AF IP addresses in the LSDBs of all connected areas. 205 If a matching IP address is found, advertised by router R in area 206 A, then mark the tunnel T as belonging to area A and terminating 207 on tail-end router R. Assign the intra-area SPF cost to reach 208 router R within area A as the IGP cost of tunnel T. 210 After completing this calculation, each TE tunnel is associated with 211 an area and tail-end router in terms of the routing LSDB of the 212 computing OSPF instance and has a cost. 214 The algorithm described above is to be used only if Node Local 215 Address sub-TLV include X-AF information. 217 Note that for clarity of description the mapping algorithm is 218 specified as a single calculation. Actual implementations for the 219 efficiency may choose to support equivalent mapping functionality 220 without implementing the algorithm exactly as it is described. 222 As an example, consider a router in a dual-stack network respectively 223 using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing. Suppose the 224 OSPFv2 instance is used to propagate MPLS TE information and the 225 router is configured to accept TE LSPs terminating at local addresses 226 198.51.100.1 and 198.51.100.2. The router advertises in OSPFv2 the 227 IPv4 address 198.51.100.1 in the Router Address TLV, the additional 228 local IPv4 address 198.51.100.2 in the Node IPv4 Local Address sub- 229 TLV, and other Traffic Engineering TLVs as required by [RFC3630]. If 230 the OSPFv3 instance in the network is enabled for X-AF TE routing 231 (that is, to use MPLS TE LSPs computed by OSPFv2 for IPv6 routing), 232 then the OSPFv3 instance of the router will advertise the Node IPv4 233 Local Address sub-TLV listing the local IPv4 addresses 198.51.100.1 234 and 198.51.100.2. Other routers in the OSPFv3 network will use this 235 information to reliably identify this router as the egress LSR for 236 MPLS TE LSPs terminating at either 198.51.100.1 or 198.51.100.2. 238 4. Backward Compatibility 240 Only routers that serve as endpoints for one or more TE tunnels MUST 241 be upgraded to support the procedures described herein: 243 o Tunnel tailend routers advertise the Node IPv4 Local Address sub- 244 TLV and/or the Node IPv6 Local Address sub-TLV. 246 o Tunnel headend routers perform the X-AF routing calculation. 248 Other routers in the network do not need to support X-AF procedures. 250 4.1. Automatically Switched Optical Networks 252 [RFC6827] updates [RFC5786] by defining extensions to be used in an 253 Automatically Switched Optical Network (ASON). The Local TE Router 254 ID Sub-TLV is required for determining ASON reachability. The 255 implication is that if the Local TE Router ID Sub-TLV is present in 256 the Node Attribute TLV, then the procedures in [RFC6827] apply, 257 regardless of whether any X-AF information is advertised. 259 5. Security Considerations 261 This document describes the use of the Local Address sub-TLVs to 262 provide X-AF information. The advertisement of these sub-TLVs, in 263 any OSPF instance, is not precluded by [RFC5786]. As such, no new 264 security threats are introduced beyond the considerations in OSPFv2 265 [RFC2328], OSPFv3 [RFC5340], and [RFC5786]. 267 The X-AF information is not used for SPF computation or normal 268 routing, so the mechanism specified here has no effect on IP routing. 269 However, generating incorrect information, or tampering with the sub- 270 TLVs may have an effect on traffic engineering computations. 271 Specifically, TE traffic may be delivered to the wrong tail-end 272 router, which could lead to suboptimal routing or even traffic loops. 273 These threats are already present in other TE-related specifications, 274 and their considerations apply here as well, including [RFC3630] and 275 [RFC5329]. 277 6. IANA Considerations 279 This document has no IANA actions. 281 7. Acknowledgements 283 The authors would like to thank Peter Psenak and Eric Osborne for 284 early discussions and Acee Lindem for discussing compatibility with 285 ASON extensions. 287 We would also like to thank the authors of RFC5786 for laying down 288 the foundation for this work. 290 8. References 292 8.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, 296 DOI 10.17487/RFC2119, March 1997, 297 . 299 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 300 (TE) Extensions to OSPF Version 2", RFC 3630, 301 DOI 10.17487/RFC3630, September 2003, 302 . 304 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 305 "Traffic Engineering Extensions to OSPF Version 3", 306 RFC 5329, DOI 10.17487/RFC5329, September 2008, 307 . 309 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 310 Local Addresses in OSPF Traffic Engineering (TE) 311 Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010, 312 . 314 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 315 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 316 May 2017, . 318 8.2. Informative References 320 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 321 DOI 10.17487/RFC2328, April 1998, 322 . 324 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 325 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 326 RFC 3906, DOI 10.17487/RFC3906, October 2004, 327 . 329 [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- 330 Multipoint Traffic-Engineered MPLS Label Switched Paths 331 (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, 332 . 334 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 335 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 336 . 338 [RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, 339 Ed., "Automatically Switched Optical Network (ASON) 340 Routing for OSPFv2 Protocols", RFC 6827, 341 DOI 10.17487/RFC6827, January 2013, 342 . 344 Authors' Addresses 346 Anton Smirnov 347 Cisco Systems, Inc. 348 De Kleetlaan 6a 349 Diegem 1831 350 Belgium 352 Email: as@cisco.com 354 Alvaro Retana 355 Futurewei Technologies, Inc. 356 2330 Central Expressway 357 Santa Clara, CA 95050 358 USA 360 Email: alvaro.retana@futurewei.com 362 Michael Barnes 363 Cisco Systems, Inc. 364 510 McCarthy Blvd. 365 Milpitas, CA 95035 366 USA 368 Email: mjbarnes@cisco.com