idnits 2.17.1 draft-smirnov-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 (January 10, 2017) is 2663 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 OSPF A. Smirnov 3 Internet-Draft A. Retana 4 Updates: 5786 (if approved) M. Barnes 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: July 14, 2017 January 10, 2017 8 OSPF Routing with Cross-Address Family MPLS Traffic Engineering Tunnels 9 draft-smirnov-ospf-xaf-te-07 11 Abstract 13 When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network 14 the Multiprotocol Label Switching (MPLS) TE Label Switched Paths 15 (LSP) infrastructure may be duplicated, even if the destination IPv4 16 and IPv6 addresses belong to the same remote router. In order to 17 achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be 18 computed over MPLS TE tunnels created using information propagated in 19 another OSPF instance. This is solved by advertising cross-address 20 family (X-AF) OSPF TE information. 22 This document describes an update to RFC5786 that allows for the easy 23 identification of a router's local X-AF IP addresses. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 14, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 TE Extensions to OSPFv2 [RFC3630] and to OSPFv3 [RFC5329] have been 74 described to support intra-area TE in IPv4 and IPv6 networks, 75 respectively. In both cases the TE database provides a tight 76 coupling between the routed protocol and TE signaling information in 77 it. In other words, any use of the TE link state database is limited 78 to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340]. 80 In a dual stack network it may be desirable to set up common MPLS TE 81 LSPs to carry traffic destined to addresses from different address 82 families on a router. The use of common LSPs eases potential 83 scalability and management concerns by halving the number of LSPs in 84 the network. Besides, it allows operators to group traffic based on 85 business characteristics and/or applications or class of service, not 86 constrained by the network protocol which carries it. 88 For example, an LSP created based on MPLS TE information propagated 89 by OSPFv2 instance can be defined to carry both IPv4 and IPv6 90 traffic, instead of having both OSPFv2 and OSPFv3 to provision a 91 separate LSP for each address family. Even if in some cases the 92 address family-specific traffic is to be separated, the calculation 93 from a common database may prove operationally beneficial. 95 A requirement when creating a common MPLS TE infrastructure is the 96 ability to reliably map the X-AF family addresses to the 97 corresponding advertising tail-end router. This mapping is a 98 challenge because the LSAs containing the routing information are 99 carried in one OSPF instance while the TE calculation may be done 100 using a TE database from a different instance. 102 A simple solution to this problem is to rely on the Router ID to 103 identify a node in the corresponding OSPFv2 and OSPFv3 databases. 104 This solution would mandate both instances on the same router to be 105 configured with the same Router ID. However, relying on the 106 correctness of the configuration puts additional burden on network 107 management and adds cost to the operation of the network. The 108 network becomes even more difficult to manage if OSPFv2 and OSPFv3 109 topologies do not match exactly, for example if area borders are 110 drawn differently in the two protocols. Also, if the routing 111 processes do fall out of sync (having different Router IDs, even if 112 for local administrative reasons), there is no defined way for other 113 routers to discover such misalignment and to take any corrective 114 measures (such as to avoid routing through affected TE tunnels or 115 issuing warning to network management). The use of misaligned router 116 IDs may result in delivering the traffic to the wrong tail-end 117 router, which could lead to suboptimal routing or even traffic loops. 119 This document describes an update to [RFC5786] that allows for the 120 easy identification of a router's local X-AF IP addresses. Routers 121 using the Node Attribute TLV [RFC5786] can include non-TE enabled 122 interface addresses in their OSPF TE advertisements, and also use the 123 same sub-TLVs to carry X-AF information, facilitating the mapping 124 mentioned above. 126 The method described in this document can also be used to compute 127 X-AF mapping of egress LSR for sub-LSPs of a Point-to-Multipoint LSP 128 (see [RFC4461]). Considerations of using Point-to-Multipoint MPLS TE 129 for X-AF traffic forwarding is outside the scope of this 130 specification. 132 2. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Operation 140 [RFC5786] defined the Node IPv4 Local Address and Node IPv6 Local 141 Address sub-TLVs of the Node Attribute TLV for a router to advertise 142 additional local IPv4 and IPv6 addresses. To solve the problem 143 outlined in [RFC5786] OSPFv2 would advertise and use only IPv4 144 addresses and OSPFv3 would advertise and use only IPv6 addresses. 146 This document updates [RFC5786] so that a router can also announce 147 one or more local X-AF addresses using the corresponding Local 148 Address sub-TLV. In other words, to implement the X-AF routing 149 technique proposed in this document, OSPFv2 will advertise the Node 150 IPv6 Local Address sub-TLV and OSPFv3 will advertise the Node IPv4 151 Local Address sub-TLV, possibly in addition to advertising other IP 152 addresses as documented by [RFC5786]. 154 A node that implements X-AF routing SHOULD advertise in the 155 corresponding Node Local Address sub-TLV all X-AF IP addresses local 156 to the router that can be used by Constrained SPF (CSPF) to calculate 157 MPLS TE LSPs. In general, OSPF SHOULD advertise the IP address 158 listed in the Router Address TLV of the X-AF instance maintaining 159 MPLS TE database plus any additional local addresses advertised by 160 the X-AF OSPF instance in its Node Local Address sub-TLV. 161 Implementation MAY advertise other local X-AF addresses. 163 If the Node Attribute TLV carries both the Node IPv4 Local Address 164 sub-TLV and the Node IPv6 Local Address sub-TLV, then the X-AF 165 component must be considered for the consolidated calculation of MPLS 166 TE LSPs. Both instances may carry the required information, it is 167 left to local configuration to determine which database is used. 169 On Area Border Routers (ABR), each advertised X-AF IP address MUST be 170 advertised into at most one area. If OSPFv2 and OSPFv3 area borders 171 match (i.e. for each interface area number for OSPFv2 and OSPFv3 172 instances is numerically equal), then the X-AF addresses MUST be 173 advertised into the same area in both instances. This allows other 174 ABRs connected to the same set of areas to know with which area to 175 associate MPLS TE tunnels. 177 During the X-AF routing calculation, X-AF IP addresses are used to 178 map locally created LSPs to tail-end routers in the LSDB. The 179 mapping algorithm can be described as: 181 Walk the list of all MPLS TE tunnels for which the computing 182 router is a head-end. For each MPLS TE tunnel T: 184 1. If T's destination IP address is from the same address family as 185 the computing OSPF instance, then the tunnel must have been 186 signaled based on MPLS TE information propagated in the same OSPF 187 instance. Process the tunnel as per [RFC3630] or [RFC5329]. 189 2. Otherwise it is a X-AF MPLS TE tunnel. Note tunnel's destination 190 IP address. 192 3. Walk the X-AF IP addresses in the LSDBs of all connected areas. 193 If a matching IP address is found, advertised by router R in area 194 A, then mark the tunnel T as belonging to area A and terminating 195 on tail-end router R. Assign an intra-area SPF cost to reach 196 router R within area A as the IGP cost of tunnel T. 198 After completing this calculation, each TE tunnel is associated with 199 an area and tail-end router in terms of the routing LSDB of the 200 computing OSPF instance and has a metric. 202 Note that for clarity of description the mapping algorithm is 203 specified as a single calculation. Actual implementations for the 204 efficiency may choose to support equivalent mapping functionality 205 without implementing the algorithm exactly as it is described. 207 As an example lets consider a router in dual-stack network running 208 OSPFv2 and OSPFv3 for IPv4 and IPv6 routing correspondingly. Suppose 209 OSPFv2 instance is used to propagate MPLS TE information and the 210 router is configured to accept TE LSPs terminating at local addresses 211 198.51.100.1 and 198.51.100.2. Then the router will advertise into 212 OSPFv2 instance IPv4 address 198.51.100.1 in the Router Address TLV, 213 additional local IPv4 address 198.51.100.2 in the Node IPv4 Local 214 Address sub-TLV, plus other Traffic Engineering TLVs as required by 215 [RFC3630]. If OSPFv3 instance in the network is enabled for X-AF TE 216 routing (that is, to use for IPv6 routing MPLS TE LSPs computed by 217 OSPFv2), then the OSPFv3 instance of the router will advertise the 218 Node IPv4 Local Address sub-TLV listing local IPv4 addresses 219 198.51.100.1 and 198.51.100.2. Other routers in the OSPFv3 network 220 will use this information to reliably identify this router as egress 221 LSR for MPLS TE LSPs terminating at either 198.51.100.1 or 222 198.51.100.2. 224 4. Backward Compatibility 226 Node Attribute TLV and Node Local Address sub-TLVs and their usage 227 are defined in [RFC5786] and updated by [RFC6827]. Way of using 228 these TLVs as specified in this document is fully backward compatible 229 with previous standard documents. 231 An implementation processing Node Attribute TLV MUST interpret its 232 content as follows: 234 o If the Node Attribute TLV contains Local TE Router ID sub-TLV then 235 this Node Attribute TLV MUST be treated as carrying routing 236 information for ASON (Automatically Switched Optical Network) and 237 processed as specified in [RFC6827]. 239 o Otherwise Node Attribute TLV contains one or more instance(s) of 240 Node IPv4 Local Address and/or Node IPv6 Local Address sub-TLVs. 242 Meaning of each Local Address sub-TLV has to be identified 243 separately. 245 * If Node Local Address sub-TLV belongs to the same address 246 family as instance of OSPF protocol advertising it then address 247 carried in the sub-TLV MUST be treated as described in 248 [RFC5786]. 250 * Otherwise the address is used for X-AF tunnel tail-end mapping 251 as defined by this document. 253 5. Security Considerations 255 This document introduces no new security concerns. Security 256 considerations of using Node Attribute TLV are discussed in 257 [RFC5786]. 259 6. IANA Considerations 261 This document has no IANA actions. 263 7. Acknowledgements 265 The authors would like to thank Peter Psenak and Eric Osborne for 266 early discussions and Acee Lindem for discussing compatibility with 267 ASON extensions. 269 We would also like to thank the authors of RFC5786 for laying down 270 the foundation for this work. 272 8. References 274 8.1. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, 278 DOI 10.17487/RFC2119, March 1997, 279 . 281 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 282 Local Addresses in OSPF Traffic Engineering (TE) 283 Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010, 284 . 286 8.2. Informative References 288 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 289 DOI 10.17487/RFC2328, April 1998, 290 . 292 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 293 (TE) Extensions to OSPF Version 2", RFC 3630, 294 DOI 10.17487/RFC3630, September 2003, 295 . 297 [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- 298 Multipoint Traffic-Engineered MPLS Label Switched Paths 299 (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, 300 . 302 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 303 "Traffic Engineering Extensions to OSPF Version 3", 304 RFC 5329, DOI 10.17487/RFC5329, September 2008, 305 . 307 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 308 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 309 . 311 [RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, 312 Ed., "Automatically Switched Optical Network (ASON) 313 Routing for OSPFv2 Protocols", RFC 6827, 314 DOI 10.17487/RFC6827, January 2013, 315 . 317 Authors' Addresses 319 Anton Smirnov 320 Cisco Systems, Inc. 321 De kleetlaan 6a 322 Diegem 1831 323 Belgium 325 Email: as@cisco.com 326 Alvaro Retana 327 Cisco Systems, Inc. 328 7025 Kit Creek Rd. 329 Research Triangle Park, NC 27709 330 USA 332 Email: aretana@cisco.com 334 Michael Barnes 335 Cisco Systems, Inc. 336 510 McCarthy Blvd. 337 Milpitas, CA 95035 338 USA 340 Email: mjbarnes@cisco.com