idnits 2.17.1 draft-ietf-ospf-xaf-te-07.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 (August 15, 2019) is 1716 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: February 16, 2020 M. Barnes 7 August 15, 2019 9 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels 10 draft-ietf-ospf-xaf-te-07 12 Abstract 14 When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 15 network, the Multiprotocol Label Switching (MPLS) TE Label Switched 16 Paths (LSP) infrastructure may be duplicated, even if the destination 17 IPv4 and IPv6 addresses belong to the same remote router. In order 18 to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must 19 be computed over MPLS TE tunnels created using information propagated 20 in another OSPF instance. This issue is solved by advertising cross- 21 address family (X-AF) OSPF TE information. 23 This document describes an update to RFC5786 that allows for the easy 24 identification of a router's local X-AF IP addresses. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 16, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 62 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 64 4.1. Automatically Switched Optical Networks . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 TE Extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been 76 described to support intra-area TE in IPv4 and IPv6 networks, 77 respectively. In both cases, the TE database provides a tight 78 coupling between the routed protocol and advertised TE signaling 79 information. In other words, any use of the TE database is limited 80 to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340]. 82 In a dual stack network, it may be desirable to set up common MPLS TE 83 LSPs to carry traffic destined to addresses from different address 84 families on a router. The use of common LSPs eases potential 85 scalability and management concerns by halving the number of LSPs in 86 the network. Besides, it allows operators to group traffic based on 87 business characteristics and/or applications or class of service, not 88 constrained by the network protocol used. 90 For example, an LSP created based on MPLS TE information propagated 91 by an OSPFv2 instance can be used to transport both IPv4 and IPv6 92 traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a 93 separate LSP for each address family. Even if in some cases the 94 address family-specific traffic is to be separated, calculation from 95 a common TE database may prove to be operationally beneficial. 97 During the SPF calculation on the TE tunnel head-end router, OSPF 98 computes shortcut routes using TE tunnels. A commonly used algorithm 99 for computing shortcuts is defined in [RFC3906]. For that, or any 100 similar, algorithm to work with a common MPLS TE infrastructure in a 101 dual-stack network, a requirement is to reliably map the X-AF 102 addresses to the corresponding tail-end router. This mapping is a 103 challenge because the LSAs containing the routing information are 104 carried in one OSPF instance while the TE calculations may be done 105 using a TE database from a different OSPF instance. 107 A simple solution to this problem is to rely on the Router ID to 108 identify a node in the corresponding OSPFv2 and OSPFv3 link state 109 databases (LSDBs). This solution would mandate both instances on the 110 same router to be configured with the same Router ID. However, 111 relying on the correctness of configuration puts additional burden 112 and cost on the operation of the network. The network becomes even 113 more difficult to manage if OSPFv2 and OSPFv3 topologies do not match 114 exactly, for example if area borders are chosen differently in the 115 two protocols. Also, if the routing processes do fall out of sync 116 (e.g., having different Router IDs for local administrative reasons), 117 there is no defined way for other routers to discover such 118 misalignment and to take corrective measures (such as to avoid 119 routing traffic through affected TE tunnels or alerting the network 120 administrators). The use of misaligned Router IDs may result in 121 delivering the traffic to the wrong tail-end router, which could lead 122 to suboptimal routing or even traffic loops. 124 This document describes an update to [RFC5786] that allows for the 125 easy identification of a router's local X-AF IP addresses. [RFC5786] 126 defined the Node IPv4 Local Address and Node IPv6 Local Address sub- 127 TLVs of the Node Attribute TLV for a router to advertise additional 128 local IPv4 and IPv6 addresses. However, [RFC5786] did not describe 129 the advertisement and usage of these sub-TLVs when the address family 130 of the advertised local address differed from the address family of 131 the OSPF traffic engineering protocol. 133 This document updates [RFC5786] so that a router can also announce 134 one or more local X-AF addresses using the corresponding Local 135 Address sub-TLV. Routers using the Node Attribute TLV [RFC5786] can 136 include non-TE enabled interface addresses in their OSPF TE 137 advertisements, and also use the same sub-TLVs to carry X-AF 138 information, facilitating the mapping described above. 140 The method specified in this document can also be used to compute the 141 X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs 142 of a Point-to-Multipoint LSP [RFC4461]. Considerations of using 143 Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside 144 the scope of this document. 146 2. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 3. Operation 156 To implement the X-AF routing technique described in this document, 157 OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3 158 will advertise the Node IPv4 Local Address sub-TLV, possibly in 159 addition to advertising other IP addresses as documented by 160 [RFC5786]. 162 Multiple instances of OSPFv3 are needed if it is used for both IPv4 163 and IPv6 [RFC5838]. The operation in this section is described with 164 OSPFv2 as the protocol used for IPv4; that is the most common case. 165 The case of OSPFv3 being used for IPv4 follows the same procedure as 166 what is indicated for OSPFv2 below. 168 On a node that implements X-AF routing, each OSPF instance 169 advertises, using the Node Local Address sub-TLV, all X-AF IPv6 (for 170 OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router 171 that can be used by Constrained SPF (CSPF) to calculate MPLS TE LSPs: 173 OSPF instance MUST advertise the IP address listed in the Router 174 Address TLV [RFC3630], [RFC5329] of the X-AF instance maintaining 175 the TE database. 177 OSPF instance SHOULD include additional local addresses advertised 178 by the X-AF OSPF instance in its Node Local Address sub-TLVs. 180 An implementation MAY advertise other local X-AF addresses. 182 When TE information is advertised in an OSPF instance both natively 183 (i.e. as per RFC [RFC3630] or [RFC5329]) and as XAF Node Attribute 184 TLV it is left to local configuration to determine which TE database 185 is used to compute routes for the OSPF instance. 187 On Area Border Routers (ABR), each advertised X-AF IP address MUST be 188 advertised into at most one area. If OSPFv2 and OSPFv3 area border 189 routers coincide (i.e., the areas for all OSPFv2 and OSPFv3 190 interfaces are the same), then the X-AF addresses MUST be advertised 191 into the same area in both instances. This allows other ABRs 192 connected to the same set of areas to know with which area to 193 associate computed MPLS TE tunnels. 195 During the X-AF routing calculation, X-AF IP addresses are used to 196 map locally created LSPs to tail-end routers in the Link State 197 Database (LSDB). The mapping algorithm can be described as: 199 Walk the list of all MPLS TE tunnels for which the computing 200 router is a head-end. For each MPLS TE tunnel T: 202 1. If T's destination address is from the same address family as the 203 OSPF instance associated with the LSDB, then the extensions 204 defined in this document do not apply. 206 2. Otherwise it is a X-AF MPLS TE tunnel. Note tunnel's destination 207 IP address. 209 3. Walk the X-AF IP addresses in the LSDBs of all connected areas. 210 If a matching IP address is found, advertised by router R in area 211 A, then mark the tunnel T as belonging to area A and terminating 212 on tail-end router R. Assign the intra-area SPF cost to reach 213 router R within area A as the IGP cost of tunnel T. 215 After completing this calculation, each TE tunnel is associated with 216 an area and tail-end router in terms of the routing LSDB of the 217 computing OSPF instance and has a cost. 219 The algorithm described above is to be used only if Node Local 220 Address sub-TLV include X-AF information. 222 Note that for clarity of description the mapping algorithm is 223 specified as a single calculation. Actual implementations for the 224 efficiency may choose to support equivalent mapping functionality 225 without implementing the algorithm exactly as it is described. 227 As an example, consider a router in a dual-stack network respectively 228 using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing. Suppose the 229 OSPFv2 instance is used to propagate MPLS TE information and the 230 router is configured to accept TE LSPs terminating at local addresses 231 198.51.100.1 and 198.51.100.2. The router advertises in OSPFv2 the 232 IPv4 address 198.51.100.1 in the Router Address TLV, the additional 233 local IPv4 address 198.51.100.2 in the Node IPv4 Local Address sub- 234 TLV, and other Traffic Engineering TLVs as required by [RFC3630]. If 235 the OSPFv3 instance in the network is enabled for X-AF TE routing 236 (that is, to use MPLS TE LSPs computed by OSPFv2 for IPv6 routing), 237 then the OSPFv3 instance of the router will advertise the Node IPv4 238 Local Address sub-TLV listing the local IPv4 addresses 198.51.100.1 239 and 198.51.100.2. Other routers in the OSPFv3 network will use this 240 information to reliably identify this router as the egress LSR for 241 MPLS TE LSPs terminating at either 198.51.100.1 or 198.51.100.2. 243 4. Backward Compatibility 245 Only routers that serve as endpoints for one or more TE tunnels MUST 246 be upgraded to support the procedures described herein: 248 o Tunnel tailend routers advertise the Node IPv4 Local Address sub- 249 TLV and/or the Node IPv6 Local Address sub-TLV. 251 o Tunnel headend routers perform the X-AF routing calculation. 253 Both the endpoints MUST be upgraded before the tailend starts 254 advertising the X-AF information. Other routers in the network do 255 not need to support X-AF procedures. 257 4.1. Automatically Switched Optical Networks 259 [RFC6827] updates [RFC5786] by defining extensions to be used in an 260 Automatically Switched Optical Network (ASON). The Local TE Router 261 ID Sub-TLV is required for determining ASON reachability. The 262 implication is that if the Local TE Router ID Sub-TLV is present in 263 the Node Attribute TLV, then the procedures in [RFC6827] apply, 264 regardless of whether any X-AF information is advertised. 266 5. Security Considerations 268 This document describes the use of the Local Address sub-TLVs to 269 provide X-AF information. The advertisement of these sub-TLVs, in 270 any OSPF instance, is not precluded by [RFC5786]. As such, no new 271 security threats are introduced beyond the considerations in OSPFv2 272 [RFC2328], OSPFv3 [RFC5340], and [RFC5786]. 274 The X-AF information is not used for SPF computation or normal 275 routing, so the mechanism specified here has no effect on IP routing. 276 However, generating incorrect information, or tampering with the sub- 277 TLVs may have an effect on traffic engineering computations. 278 Specifically, TE traffic may be delivered to the wrong tail-end 279 router, which could lead to suboptimal routing, traffic loops, or 280 even expose the traffic to attacker inspection or modification. 281 These threats are already present in other TE-related specifications, 282 and their considerations apply here as well, including [RFC3630] and 283 [RFC5329]. 285 6. IANA Considerations 287 This document has no IANA actions. 289 7. Acknowledgements 291 The authors would like to thank Peter Psenak and Eric Osborne for 292 early discussions and Acee Lindem for discussing compatibility with 293 ASON extensions. Also, Eric Vyncke, Ben Kaduk and Roman Danyliw 294 provided useful comments. 296 We would also like to thank the authors of RFC5786 for laying down 297 the foundation for this work. 299 8. References 301 8.1. Normative References 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, 305 DOI 10.17487/RFC2119, March 1997, 306 . 308 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 309 (TE) Extensions to OSPF Version 2", RFC 3630, 310 DOI 10.17487/RFC3630, September 2003, 311 . 313 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 314 "Traffic Engineering Extensions to OSPF Version 3", 315 RFC 5329, DOI 10.17487/RFC5329, September 2008, 316 . 318 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 319 Local Addresses in OSPF Traffic Engineering (TE) 320 Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010, 321 . 323 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 324 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 325 May 2017, . 327 8.2. Informative References 329 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 330 DOI 10.17487/RFC2328, April 1998, 331 . 333 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 334 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 335 RFC 3906, DOI 10.17487/RFC3906, October 2004, 336 . 338 [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- 339 Multipoint Traffic-Engineered MPLS Label Switched Paths 340 (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, 341 . 343 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 344 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 345 . 347 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 348 R. Aggarwal, "Support of Address Families in OSPFv3", 349 RFC 5838, DOI 10.17487/RFC5838, April 2010, 350 . 352 [RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, 353 Ed., "Automatically Switched Optical Network (ASON) 354 Routing for OSPFv2 Protocols", RFC 6827, 355 DOI 10.17487/RFC6827, January 2013, 356 . 358 Authors' Addresses 360 Anton Smirnov 361 Cisco Systems, Inc. 362 De Kleetlaan 6a 363 Diegem 1831 364 Belgium 366 Email: as@cisco.com 368 Alvaro Retana 369 Futurewei Technologies, Inc. 370 2330 Central Expressway 371 Santa Clara, CA 95050 372 USA 374 Email: alvaro.retana@futurewei.com 376 Michael Barnes 378 Email: michael_barnes@usa.net