idnits 2.17.1 draft-ietf-ospf-xaf-te-03.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 (October 3, 2018) is 2004 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: April 6, 2019 M. Barnes 7 Cisco Systems, Inc. 8 October 3, 2018 10 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels 11 draft-ietf-ospf-xaf-te-03 13 Abstract 15 When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network 16 the Multiprotocol Label Switching (MPLS) TE Label Switched Paths 17 (LSP) infrastructure may be duplicated, even if the destination IPv4 18 and IPv6 addresses belong to the same remote router. In order to 19 achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be 20 computed over MPLS TE tunnels created using information propagated in 21 another OSPF instance. This is solved by advertising cross-address 22 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 April 6, 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 . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 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 to 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 TE signaling information in 79 it. In other words, any use of the TE link state 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 which carries it. 90 For example, an LSP created based on MPLS TE information propagated 91 by OSPFv2 instance can be defined to carry both IPv4 and IPv6 92 traffic, instead of having 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, the calculation 95 from a common database may prove operationally beneficial. 97 A requirement when creating a common MPLS TE infrastructure is the 98 ability to reliably map the X-AF family addresses to the 99 corresponding advertising tail-end router. This mapping is a 100 challenge because the LSAs containing the routing information are 101 carried in one OSPF instance while the TE calculation may be done 102 using a TE database from a different instance. 104 A simple solution to this problem is to rely on the Router ID to 105 identify a node in the corresponding OSPFv2 and OSPFv3 databases. 106 This solution would mandate both instances on the same router to be 107 configured with the same Router ID. However, relying on the 108 correctness of the configuration puts additional burden on network 109 management and adds cost to the operation of the network. The 110 network becomes even more difficult to manage if OSPFv2 and OSPFv3 111 topologies do not match exactly, for example if area borders are 112 drawn differently in the two protocols. Also, if the routing 113 processes do fall out of sync (having different Router IDs, even if 114 for local administrative reasons), there is no defined way for other 115 routers to discover such misalignment and to take any corrective 116 measures (such as to avoid routing through affected TE tunnels or 117 issuing warning to network management). The use of misaligned router 118 IDs may result in delivering the traffic to the wrong tail-end 119 router, which could lead to suboptimal routing or even traffic loops. 121 This document describes an update to [RFC5786] that allows for the 122 easy identification of a router's local X-AF IP addresses. Routers 123 using the Node Attribute TLV [RFC5786] can include non-TE enabled 124 interface addresses in their OSPF TE advertisements, and also use the 125 same sub-TLVs to carry X-AF information, facilitating the mapping 126 mentioned above. 128 The method described in this document can also be used to compute 129 X-AF mapping of egress LSR for sub-LSPs of a Point-to-Multipoint LSP 130 (see [RFC4461]). Considerations of using Point-to-Multipoint MPLS TE 131 for X-AF traffic forwarding is outside the scope of this 132 specification. 134 2. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 3. Operation 144 [RFC5786] defined the Node IPv4 Local Address and Node IPv6 Local 145 Address sub-TLVs of the Node Attribute TLV for a router to advertise 146 additional local IPv4 and IPv6 addresses. To solve the problem 147 outlined in [RFC5786] OSPFv2 would advertise and use only IPv4 148 addresses and OSPFv3 would advertise and use only IPv6 addresses. 150 This document updates [RFC5786] so that a router can also announce 151 one or more local X-AF addresses using the corresponding Local 152 Address sub-TLV. In other words, to implement the X-AF routing 153 technique proposed in this document, OSPFv2 will advertise the Node 154 IPv6 Local Address sub-TLV and OSPFv3 will advertise the Node IPv4 155 Local Address sub-TLV, possibly in addition to advertising other IP 156 addresses as documented by [RFC5786]. 158 A node that implements X-AF routing SHOULD advertise in the 159 corresponding Node Local Address sub-TLV all X-AF IP addresses local 160 to the router that can be used by Constrained SPF (CSPF) to calculate 161 MPLS TE LSPs. In general, OSPF SHOULD advertise the IP address 162 listed in the Router Address TLV of the X-AF instance maintaining 163 MPLS TE database plus any additional local addresses advertised by 164 the X-AF OSPF instance in its Node Local Address sub-TLV. 165 Implementation MAY advertise other local X-AF addresses. 167 If the Node Attribute TLV carries both the Node IPv4 Local Address 168 sub-TLV and the Node IPv6 Local Address sub-TLV, then the X-AF 169 component must be considered for the consolidated calculation of MPLS 170 TE LSPs. Both instances may carry the required information, it is 171 left to local configuration to determine which database is used. 173 On Area Border Routers (ABR), each advertised X-AF IP address MUST be 174 advertised into at most one area. If OSPFv2 and OSPFv3 area borders 175 match (i.e. for each interface area number for OSPFv2 and OSPFv3 176 instances is numerically equal), then the X-AF addresses MUST be 177 advertised into the same area in both instances. This allows other 178 ABRs connected to the same set of areas to know with which area to 179 associate MPLS TE tunnels. 181 During the X-AF routing calculation, X-AF IP addresses are used to 182 map locally created LSPs to tail-end routers in the LSDB. The 183 mapping algorithm can be described as: 185 Walk the list of all MPLS TE tunnels for which the computing 186 router is a head-end. For each MPLS TE tunnel T: 188 1. If T's destination IP address is from the same address family as 189 the computing OSPF instance, then the tunnel must have been 190 signaled based on MPLS TE information propagated in the same OSPF 191 instance. Process the tunnel as per [RFC3630] or [RFC5329]. 193 2. Otherwise it is a X-AF MPLS TE tunnel. Note tunnel's destination 194 IP address. 196 3. Walk the X-AF IP addresses in the LSDBs of all connected areas. 197 If a matching IP address is found, advertised by router R in area 198 A, then mark the tunnel T as belonging to area A and terminating 199 on tail-end router R. Assign an intra-area SPF cost to reach 200 router R within area A as the IGP cost of tunnel T. 202 After completing this calculation, each TE tunnel is associated with 203 an area and tail-end router in terms of the routing LSDB of the 204 computing OSPF instance and has a metric. 206 Note that for clarity of description the mapping algorithm is 207 specified as a single calculation. Actual implementations for the 208 efficiency may choose to support equivalent mapping functionality 209 without implementing the algorithm exactly as it is described. 211 As an example lets consider a router in dual-stack network running 212 OSPFv2 and OSPFv3 for IPv4 and IPv6 routing correspondingly. Suppose 213 OSPFv2 instance is used to propagate MPLS TE information and the 214 router is configured to accept TE LSPs terminating at local addresses 215 198.51.100.1 and 198.51.100.2. Then the router will advertise into 216 OSPFv2 instance IPv4 address 198.51.100.1 in the Router Address TLV, 217 additional local IPv4 address 198.51.100.2 in the Node IPv4 Local 218 Address sub-TLV, plus other Traffic Engineering TLVs as required by 219 [RFC3630]. If OSPFv3 instance in the network is enabled for X-AF TE 220 routing (that is, to use for IPv6 routing MPLS TE LSPs computed by 221 OSPFv2), then the OSPFv3 instance of the router will advertise the 222 Node IPv4 Local Address sub-TLV listing local IPv4 addresses 223 198.51.100.1 and 198.51.100.2. Other routers in the OSPFv3 network 224 will use this information to reliably identify this router as egress 225 LSR for MPLS TE LSPs terminating at either 198.51.100.1 or 226 198.51.100.2. 228 4. Backward Compatibility 230 Node Attribute TLV and Node Local Address sub-TLVs and their usage 231 are defined in [RFC5786] and updated by [RFC6827]. Way of using 232 these TLVs as specified in this document is fully backward compatible 233 with previous standard documents. 235 An implementation processing Node Attribute TLV MUST interpret its 236 content as follows: 238 o If the Node Attribute TLV contains Local TE Router ID sub-TLV then 239 this Node Attribute TLV MUST be treated as carrying routing 240 information for ASON (Automatically Switched Optical Network) and 241 processed as specified in [RFC6827]. 243 o Otherwise Node Attribute TLV contains one or more instance(s) of 244 Node IPv4 Local Address and/or Node IPv6 Local Address sub-TLVs. 245 Meaning of each Local Address sub-TLV has to be identified 246 separately. 248 * If Node Local Address sub-TLV belongs to the same address 249 family as instance of OSPF protocol advertising it then address 250 carried in the sub-TLV MUST be treated as described in 251 [RFC5786]. 253 * Otherwise the address is used for X-AF tunnel tail-end mapping 254 as defined by this document. 256 Only routers that serve as endpoints for one or more TE tunnels MUST 257 be upgraded to support procedures described in this document: 259 o Tunnel tailends need to advertise Node IPv4 Local Address and/or 260 Node IPv6 Local Address sub-TLVs as described in this 261 specification 263 o Tunnel headends need to perform X-AF routing calculation as 264 described in this specification 266 Other routers in the network do not need to support X-AF procedures. 268 5. Security Considerations 270 This document introduces no new security concerns. Security 271 considerations of using Node Attribute TLV are discussed in 272 [RFC5786]. 274 6. IANA Considerations 276 This document has no IANA actions. 278 7. Acknowledgements 280 The authors would like to thank Peter Psenak and Eric Osborne for 281 early discussions and Acee Lindem for discussing compatibility with 282 ASON extensions. 284 We would also like to thank the authors of RFC5786 for laying down 285 the foundation for this work. 287 8. References 289 8.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 297 Local Addresses in OSPF Traffic Engineering (TE) 298 Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010, 299 . 301 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 302 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 303 May 2017, . 305 8.2. Informative References 307 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 308 DOI 10.17487/RFC2328, April 1998, 309 . 311 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 312 (TE) Extensions to OSPF Version 2", RFC 3630, 313 DOI 10.17487/RFC3630, September 2003, 314 . 316 [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- 317 Multipoint Traffic-Engineered MPLS Label Switched Paths 318 (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, 319 . 321 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 322 "Traffic Engineering Extensions to OSPF Version 3", 323 RFC 5329, DOI 10.17487/RFC5329, September 2008, 324 . 326 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 327 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 328 . 330 [RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, 331 Ed., "Automatically Switched Optical Network (ASON) 332 Routing for OSPFv2 Protocols", RFC 6827, 333 DOI 10.17487/RFC6827, January 2013, 334 . 336 Authors' Addresses 338 Anton Smirnov 339 Cisco Systems, Inc. 340 De kleetlaan 6a 341 Diegem 1831 342 Belgium 344 Email: as@cisco.com 346 Alvaro Retana 347 Huawei R&D USA 348 2330 Central Expressway 349 Santa Clara, CA 95050 350 USA 352 Email: alvaro.retana@huawei.com 354 Michael Barnes 355 Cisco Systems, Inc. 356 510 McCarthy Blvd. 357 Milpitas, CA 95035 358 USA 360 Email: mjbarnes@cisco.com