idnits 2.17.1 draft-ietf-ospf-xaf-te-05.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 (December 10, 2018) is 1964 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 Huawei R&D USA 6 Expires: June 13, 2019 M. Barnes 7 Cisco Systems, Inc. 8 December 10, 2018 10 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels 11 draft-ietf-ospf-xaf-te-05 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 June 13, 2019. 44 Copyright Notice 46 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . 3 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 link state database 81 is limited to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 82 [RFC5340]. 84 In a dual stack network, it may be desirable to set up common MPLS TE 85 LSPs to carry traffic destined to addresses from different address 86 families on a router. The use of common LSPs eases potential 87 scalability and management concerns by halving the number of LSPs in 88 the network. Besides, it allows operators to group traffic based on 89 business characteristics and/or applications or class of service, not 90 constrained by the network protocol used. 92 For example, an LSP created based on MPLS TE information propagated 93 by an OSPFv2 instance can be used to transport both IPv4 and IPv6 94 traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a 95 separate LSP for each address family. Even if in some cases the 96 address family-specific traffic is to be separated, calculation from 97 a common database may prove to be operationally beneficial. 99 During the SPF calculation on the TE tunnel head-end router, OSPF 100 computes shortcut routes using TE tunnels. A commonly used algorithm 101 for computing shortcuts is defined in [RFC3906]. For that, or any 102 similar, algorithm to work with a common MPLS TE infrastructure in a 103 dual-stack network, a requirement is to reliably map the X-AF 104 addresses to the corresponding tail-end router. This mapping is a 105 challenge because the LSAs containing the routing information are 106 carried in one OSPF instance while the TE calculations may be done 107 using a TE database from a different OSPF instance. 109 A simple solution to this problem is to rely on the Router ID to 110 identify a node in the corresponding OSPFv2 and OSPFv3 databases. 111 This solution would mandate both instances on the same router to be 112 configured with the same Router ID. However, relying on the 113 correctness of configuration puts additional burden and cost on the 114 operation of the network. The network becomes even more difficult to 115 manage if OSPFv2 and OSPFv3 topologies do not match exactly, for 116 example if area borders are chosen differently in the two protocols. 117 Also, if the routing processes do fall out of sync (e.g., having 118 different Router IDs for local administrative reasons), there is no 119 defined way for other routers to discover such misalignment and to 120 take corrective measures (such as to avoid routing traffic through 121 affected TE tunnels or alerting the network administrators). The use 122 of misaligned Router IDs may result in delivering the traffic to the 123 wrong tail-end router, which could lead to suboptimal routing or even 124 traffic loops. 126 This document describes an update to [RFC5786] that allows for the 127 easy identification of a router's local X-AF IP addresses. Routers 128 using the Node Attribute TLV [RFC5786] can include non-TE enabled 129 interface addresses in their OSPF TE advertisements, and also use the 130 same sub-TLVs to carry X-AF information, facilitating the mapping 131 described above. 133 The method specified in this document can also be used to compute the 134 X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs 135 of a Point-to-Multipoint LSP [RFC4461]. Considerations of using 136 Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside 137 the scope of this document. 139 2. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 3. Operation 149 [RFC5786] defined the Node IPv4 Local Address and Node IPv6 Local 150 Address sub-TLVs of the Node Attribute TLV for a router to advertise 151 additional local IPv4 and IPv6 addresses. However, [RFC5786] did not 152 describe the advertisement and usage of these sub-TLVs when the 153 address family of the advertised local address differed from the 154 address family of the OSPF traffic engineering protocol. 156 This document updates [RFC5786] so that a router can also announce 157 one or more local X-AF addresses using the corresponding Local 158 Address sub-TLV. In other words, to implement the X-AF routing 159 technique described in this document, OSPFv2 will advertise the Node 160 IPv6 Local Address sub-TLV and OSPFv3 will advertise the Node IPv4 161 Local Address sub-TLV, possibly in addition to advertising other IP 162 addresses as documented by [RFC5786]. 164 A node that implements X-AF routing SHOULD advertise, in the 165 corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6 166 addresses local to the router that can be used by Constrained SPF 167 (CSPF) to calculate MPLS TE LSPs. OSPF MUST advertise the IP address 168 listed in the Router Address TLV [RFC3630] [RFC5329] of the X-AF 169 instance maintaining the MPLS TE database, and SHOULD include 170 additional local addresses advertised by the X-AF OSPF instance in 171 its Node Local Address sub-TLVs. An implementation MAY advertise 172 other local X-AF addresses. 174 If the Node Attribute TLV carries both the Node IPv4 Local Address 175 sub-TLV and the Node IPv6 Local Address sub-TLV, then the X-AF 176 component MUST be considered for the consolidated calculation of MPLS 177 TE LSPs. Both instances MAY advertise the required information and 178 it is left to local configuration to determine which database is 179 used. 181 On Area Border Routers (ABR), each advertised X-AF IP address MUST be 182 advertised into at most one area. If OSPFv2 and OSPFv3 area border 183 routers coincide (i.e., the areas for all OSPFv2 and OSPFv3 184 interfaces are the same), then the X-AF addresses MUST be advertised 185 into the same area in both instances. This allows other ABRs 186 connected to the same set of areas to know with which area to 187 associate computed MPLS TE tunnels. 189 During the X-AF routing calculation, X-AF IP addresses are used to 190 map locally created LSPs to tail-end routers in the Link State 191 Database (LSDB). The mapping algorithm can be described as: 193 Walk the list of all MPLS TE tunnels for which the computing 194 router is a head-end. For each MPLS TE tunnel T: 196 1. If T's destination address is from the same address family as the 197 OSPF instance associated with the LSDB, then the extensions 198 defined in this document do not apply. 200 2. Otherwise it is a X-AF MPLS TE tunnel. Note tunnel's destination 201 IP address. 203 3. Walk the X-AF IP addresses in the LSDBs of all connected areas. 204 If a matching IP address is found, advertised by router R in area 205 A, then mark the tunnel T as belonging to area A and terminating 206 on tail-end router R. Assign the intra-area SPF cost to reach 207 router R within area A as the IGP cost of tunnel T. 209 After completing this calculation, each TE tunnel is associated with 210 an area and tail-end router in terms of the routing LSDB of the 211 computing OSPF instance and has a cost. 213 The algorithm described above is to be used only if Node Local 214 Address sub-TLV include X-AF information. 216 Note that for clarity of description the mapping algorithm is 217 specified as a single calculation. Actual implementations for the 218 efficiency may choose to support equivalent mapping functionality 219 without implementing the algorithm exactly as it is described. 221 As an example, consider a router in a dual-stack network respectively 222 using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing. Suppose the 223 OSPFv2 instance is used to propagate MPLS TE information and the 224 router is configured to accept TE LSPs terminating at local addresses 225 198.51.100.1 and 198.51.100.2. The router advertises in OSPFv2 the 226 IPv4 address 198.51.100.1 in the Router Address TLV, the additional 227 local IPv4 address 198.51.100.2 in the Node IPv4 Local Address sub- 228 TLV, and other Traffic Engineering TLVs as required by [RFC3630]. If 229 the OSPFv3 instance in the network is enabled for X-AF TE routing 230 (that is, to use MPLS TE LSPs computed by OSPFv2 for IPv6 routing), 231 then the OSPFv3 instance of the router will advertise the Node IPv4 232 Local Address sub-TLV listing the local IPv4 addresses 198.51.100.1 233 and 198.51.100.2. Other routers in the OSPFv3 network will use this 234 information to reliably identify this router as the egress LSR for 235 MPLS TE LSPs terminating at either 198.51.100.1 or 198.51.100.2. 237 4. Backward Compatibility 239 Only routers that serve as endpoints for one or more TE tunnels MUST 240 be upgraded to support the procedures described herein: 242 o Tunnel tailend routers advertise the Node IPv4 Local Address sub- 243 TLV and/or the Node IPv6 Local Address sub-TLV. 245 o Tunnel headend routers perform the X-AF routing calculation. 247 Other routers in the network do not need to support X-AF procedures. 249 4.1. Automatically Switched Optical Networks 251 [RFC6827] updates [RFC5786] by defining extensions to be used in an 252 Automatically Switched Optical Network (ASON). The Local TE Router 253 ID Sub-TLV is required for determining ASON reachability. The 254 implication is that if the Local TE Router ID Sub-TLV is present in 255 the Node Attribute TLV, then the procedures in [RFC6827] apply, 256 regardless of whether any X-AF information is advertised. 258 5. Security Considerations 260 This document describes the use of the Local Address sub-TLVs to 261 provide X-AF information. The advertisement of these sub-TLVs, in 262 any OSPF instance, is not precluded by [RFC5786]. As such, no new 263 security threats are introduced beyond the considerations in OSPFv2 264 [RFC2328], OSPFv3 [RFC5340], and [RFC5786]. 266 The X-AF information is not used for SPF computation or normal 267 routing, so the mechanism specified here has no affect on IP routing. 268 However, generating incorrect information, or tampering with the sub- 269 TLVs may have an effect on traffic engineering computations. 270 Specifically, TE traffic may be delivered to the wrong tail-end 271 router, which could lead to suboptimal routing or even traffic loops. 272 These threats are already present in other TE-related specifications, 273 and their considerations apply here as well, including [RFC3630] and 274 [RFC5329]. 276 6. IANA Considerations 278 This document has no IANA actions. 280 7. Acknowledgements 282 The authors would like to thank Peter Psenak and Eric Osborne for 283 early discussions and Acee Lindem for discussing compatibility with 284 ASON extensions. 286 We would also like to thank the authors of RFC5786 for laying down 287 the foundation for this work. 289 8. References 291 8.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, 295 DOI 10.17487/RFC2119, March 1997, 296 . 298 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 299 Local Addresses in OSPF Traffic Engineering (TE) 300 Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010, 301 . 303 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 304 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 305 May 2017, . 307 8.2. Informative References 309 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 310 DOI 10.17487/RFC2328, April 1998, 311 . 313 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 314 (TE) Extensions to OSPF Version 2", RFC 3630, 315 DOI 10.17487/RFC3630, September 2003, 316 . 318 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 319 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 320 RFC 3906, DOI 10.17487/RFC3906, October 2004, 321 . 323 [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- 324 Multipoint Traffic-Engineered MPLS Label Switched Paths 325 (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, 326 . 328 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 329 "Traffic Engineering Extensions to OSPF Version 3", 330 RFC 5329, DOI 10.17487/RFC5329, September 2008, 331 . 333 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 334 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 335 . 337 [RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, 338 Ed., "Automatically Switched Optical Network (ASON) 339 Routing for OSPFv2 Protocols", RFC 6827, 340 DOI 10.17487/RFC6827, January 2013, 341 . 343 Authors' Addresses 345 Anton Smirnov 346 Cisco Systems, Inc. 347 De kleetlaan 6a 348 Diegem 1831 349 Belgium 351 Email: as@cisco.com 353 Alvaro Retana 354 Huawei R&D USA 355 2330 Central Expressway 356 Santa Clara, CA 95050 357 USA 359 Email: alvaro.retana@huawei.com 361 Michael Barnes 362 Cisco Systems, Inc. 363 510 McCarthy Blvd. 364 Milpitas, CA 95035 365 USA 367 Email: mjbarnes@cisco.com