idnits 2.17.1 draft-vasseur-mpls-nodeid-subobject-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 473 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 198 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([INTER-AS-TE], [MULTI-AREA-TE], [RSVP-TE], [LOOSE-PATH-REOPT], [INTER-AS-TE-REQS], [RSVP,RSVP-TE], [ISIS-TE], [RSVP], [ABR-ASBR-FRR], [OSPF-TE], [FAST-REROUTE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The node-id subobject is added into the RECORD_ROUTE object after the Label Record subobject. A node MUST not push a node-id subobject without also pushing an IPv4 or IPv6 subobjects, as defined in [FAST-REROUTE]. A node may push both IPv4 node-id and IPv6 node-id sub-objects, but that MUST be done on consistent basis. -- 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 (February 2003) is 7735 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) -- Missing reference section? 'FAST-REROUTE' on line 361 looks like a reference -- Missing reference section? 'RSVP-TE' on line 354 looks like a reference -- Missing reference section? 'RSVP' on line 351 looks like a reference -- Missing reference section? 'OSPF-TE' on line 364 looks like a reference -- Missing reference section? 'ISIS-TE' on line 368 looks like a reference -- Missing reference section? 'INTER-AS-TE-REQS' on line 382 looks like a reference -- Missing reference section? 'MULTI-AREA-TE' on line 371 looks like a reference -- Missing reference section? 'LOOSE-PATH-REOPT' on line 374 looks like a reference -- Missing reference section? 'ABR-ASBR-FRR' on line 378 looks like a reference -- Missing reference section? 'INTER-AS-TE' on line 385 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft-vasseur-mpls-nodeid-subobject-00.txt February 2003 4 Jean Philippe Vasseur 5 Zafar Ali 6 Siva Sivabalan 7 Cisco Systems, Inc. 9 IETF Internet Draft 10 Expires: August, 2003 11 February, 2003 13 draft-vasseur-mpls-nodeid-subobject-00.txt 15 Definition of an RRO node-id subobject 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC2026. Internet-Drafts are 21 Working documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Vasseur, Ali and Sivabalan 1 37 draft-vasseur-mpls-nodeid-subobject-00.txt February 2003 39 Abstract 41 In the context of MPLS TE Fast Reroute ([FAST-REROUTE]), the Merge 42 Point (MP) address is required at the Point of Local Repair (PLR) in 43 order to select a backup tunnel intersecting a protected Traffic 44 Engineering LSP on a downstream LSR. However, existing protocol 45 mechanisms are not sufficient to find MP address multi-areas or multi- 46 domain routing network. Hence, the current MPLS Fast Reroute mechanism 47 cannot be used to protect inter-area or inter-AS TE LSPs from a failure 48 of an ABR (Area Border Router) or ASBR (Autonomous System Border 49 Router) respectively. This document specifies the use of existing RRO 50 IPv4 and IPv6 subobjects (with a new flag defined) to define the node- 51 id subobject in order to solve this issue. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC-2119 [i]. 59 1. Terminology 61 LSR - Label Switch Router 63 LSP - An MPLS Label Switched Path 65 PCS - Path Computation Server (may be any kind of LSR (ABR, ...) 66 or a centralized path computation server 68 PCC - Path Computation Client (any head-end LSR) requesting a path 69 computation of the Path Computation Server. 71 Local Repair - Techniques used to repair LSP tunnels quickly 72 when a node or link along the LSPs path fails. 74 Protected LSP - An LSP is said to be protected at a given hop if 75 it has one or multiple associated backup tunnels 76 originating at that hop. 78 Bypass Tunnel - An LSP that is used to protect a set of LSPs 79 passing over a common facility. 81 Backup Tunnel - The LSP that is used to backup up one of the many 82 LSPs in many-to-one backup. 84 PLR - Point of Local Repair. The head-end of a backup tunnel or 85 a detour LSP. 87 MP - Merge Point. The LSR where detour or backup tunnels meet 89 Vasseur, Ali and Sivabalan 2 91 draft-vasseur-mpls-nodeid-subobject-00.txt February 2003 93 the protected LSP. In case of one-to-one backup, this is where 94 multiple detours converge. A MP may also be a PLR. 96 NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel 97 which bypasses a single link of the protected LSP. 99 NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup 100 tunnel which bypasses a single node of the protected LSP. 102 Reroutable LSP - Any LSP for with the "Local protection desired" 103 bit is set in the Flag field of the 104 SESSION_ATTRIBUTE object of its Path messages. 106 CSPF - Constraint-based Shortest Path First. 108 Inter-AS MPLS TE: TE LSP whose Head-end LSR and Tail-end LSR do 109 not reside within the same Autonomous System (AS) or both Head-end 110 LSR and Tail-end LSR are in the same AS but the TE tunnel 111 transiting path may be across different ASes 113 Interconnect or ASBR Routers: Routers used to connect to another AS of 114 a different or the same Service Provider via one or more Inter-AS 115 links. 117 2. Introduction 119 MPLS Fast Reroute (FRR) ([FAST-REROUTE]) is a fast recovery local 120 protection technique used to protect Traffic Engineering LSPs from 121 link/SRLG/node failure. One or more TE LSPs (called backup LSPs) are 122 pre-established to protect against the failure of a link/node/SRLG. In 123 case of failure, every protected TE LSP traversing the failed resource 124 is rerouted onto the appropriate backup tunnels in 10s of msecs. 126 There are a couple of requirements on the backup tunnel path. At least, 127 a backup tunnel should not pass through the element it protects. 128 Additionally, a primary tunnel and a backup tunnel should intersect at 129 least at two points (nodes): Point of Local Repair (PLR) and Merge 130 Point (MP). The former should be the head-end LSR of the backup tunnel, 131 and the latter should be the tail-end LSR of the backup tunnel. The PLR 132 is where FRR is triggered when link/node/SRLG failure happens. 133 Furthermore, the MP address is also required to send RSVP Refresh 134 messages of the rerouted TE LSPs when the FRR is active. 136 There are different methods for computing paths for backup tunnels. 137 Specifically, a users can statically configures one or more backup 138 tunnels at the PLR, with explicit path or the PLR can be configured to 139 automatically compute a backup path or to send a path computation 140 request to a PCS (which can be an LSR or an off-line tool). 141 Consider the following scenario 143 Vasseur, Ali and Sivabalan 3 145 draft-vasseur-mpls-nodeid-subobject-00.txt February 2003 147 Asumptions: 148 - a multi-area network made of three areas: 0, 1 and 2. 149 - a protected TE LSP T1 (TE LSP signaled with the "local Protection 150 desired" bit set in the SESSION-ATTRIBUTE object or the FRR object) 151 from R0 to R3 152 - a backup tunnel B1 from R1 to R2, not traversing ABR1, and following 153 the R1-ABR3-R2 path. R1 reroutes any protected TE LSP traversing ABR1 154 onto the backup tunnel B1 in case of ABR1's failure. 156 <--- area 1 --><---area 0---><---area 2---> 157 R0-----R1-ABR1--R2------ABR2--------R3 158 \ / 159 \ ABR3 / 161 When T1 is first signaled, the PLR R1 needs to dynamically select an 162 appropriate backup tunnel intersecting T1 on a downstream LSR. However, 163 existing protocol mechanisms are not sufficient to unambiguously find 164 MP address in a network with inter-area or inter-AS traffic engineering 165 (although the example above was given in the context of multi-area 166 networks, a similar reasoning applies to TE LSP spanning multiple 167 ASes). This draft addresses these limitations. 169 R1 needs to ensure the following: 171 1. Backup tunnel intersects with the primary tunnel at the MP (and 172 thus has a valid MP address), e.g., in Figure 1, R1 needs to 173 determine that T1 and B1 share the same MP node R2, 175 2. Backup tunnel satisfies the primary LSP's request with respect to 176 the bandwidth protection request (i.e., bandwidth guaranteed for 177 the primary tunnel during failure), and the type of protection 178 (preferably, protecting against a node failure versus a link 179 failure), as specified in [FAST-REROUTE]. 181 A PLR can make sure that condition (1) is met by examining the Record 182 Route Object (RRO) of the primary tunnel to see if any of the addresses 183 specified in the RRO is attached to the tail-end of the backup tunnel. 184 As per [RSVP-TE], the addresses specified in the RRO IPv4 subobjects 185 can be node-ids and/or interface addresses, with specific 186 recommendation to use the interface address of the outgoing Path 187 messages. Hence, in Figure 1, router R2 is more likely to specify 188 interface addresses in the RROs for T1 and B1. Note that these 189 interface addresses are different in this example. 191 The problem of finding the MP using the interface addresses or node-ids 192 can be easily solved in a single area TE. Specifically, in the case of 193 single area TE, the PLR has the knowledge of all the interfaces 194 attached to the tail-end of the backup tunnel. This information is 195 available in PLR's IGP topology database. Thus, the PLR can determine 196 whether a backup tunnel intersecting a protected TE LSP on a downstream 197 node exists and can also find the MP address regardless of how the 199 Vasseur, Ali and Sivabalan 4 201 draft-vasseur-mpls-nodeid-subobject-00.txt February 2003 203 addresses contained in the RRO IPv4 or IPv6 subobjects are specified 204 (i.e., whether using the interface addresses or the node IDs). However, 205 such routing information is not available in a multi-area and inter-AS 206 traffic-engineering environments. Hence, unambiguously making sure that 207 condition (1) above is met with inter-area TE and inter-AS traffic- 208 engineering TE LSPs is not possible with existing mechanisms. 210 In this draft, we define extensions to and describe the use of RSVP 211 [RSVP, RSVP-TE] to solve the above-mentioned problem. 213 3. Signaling node-ids in RROs 215 As mentioned above, the limitation that we need to address is the 216 generality of the contents of the RRO IPv4 and IPv6 subobjects, as 217 defined in [RSVP-TE]. 219 The IPv4 and IPv6 RRO subobjects are currently defined in [RSVP-TE] and 220 have the following flags defined: 222 Local protection available: 0x01 224 Indicates that the link downstream of this node is protected 225 via a local repair mechanism, which can be either one-to-one 226 or facility backup. 228 Local protection in use: 0x02 230 Indicates that a local repair mechanism is in use to maintain 231 this tunnel (usually in the face of an outage of the link it 232 was previously routed over, or an outage of the neighboring 233 node). 235 Bandwidth protection: 0x04 237 The PLR will set this when the protected LSP has a backup path 238 which is guaranteed to provide the desired bandwidth specified 239 in the FAST_REROUTE object or the bandwidth of the protected 240 LSP, if no FAST_REROUTE object was included. The PLR may set 241 this whenever the desired bandwidth is guaranteed; the PLR 242 MUST set this flag when the desired bandwidth is guaranteed 243 and the "bandwidth protection desired" flag was set in the 244 SESSION_ATTRIBUTE object. If the requested bandwidth is not 245 guaranteed, the PLR MUST NOT set this flag. 247 Node protection: 0x08 249 The PLR will set this when the protected LSP has a backup path 250 which provides protection against a failure of the next LSR 251 along the protected LSP. The PLR may set this whenever node 252 protection is provided by the protected LSP's backup path; the 254 Vasseur, Ali and Sivabalan 5 256 draft-vasseur-mpls-nodeid-subobject-00.txt February 2003 258 PLR MUST set this flag when the node protection is provided 259 and the "node protection desired" flag was set in the 260 SESSION_ATTRIBUTE object. If node protection is not provided, 261 the PLR MUST NOT set this flag. Thus, if a PLR could only 262 setup a link-protection backup path, the "Local protection 263 available" bit will be set but the "Node protection" bit will 264 be cleared. 266 An additional flag is specified: 268 Node-id: 0x10 270 When set, this indicates that the address specified in the RRO 271 IPv4 or IPv6 subobject is a node-id address, which refers to 272 the "Router Address" as defined in [OSPF-TE], or "Traffic 273 Engineering Router ID" as defined in [ISIS-TE]. A node MUST use 274 the same address consistently. 276 An IPv4 or IPv6 RRO subobject with the node-is flag set is also called 277 a node-id subobject. 279 The problem of finding MP address in a network with inter-area or 280 inter-AS traffic engineering is solved by adding a node-id subobject 281 (an RRO "IPv4" and "IPv6" sub-object with the 0x10 flag set). 283 Any Head-end LSR of a protected TE LSP MUST include an RRO object, as 284 defined in [FAST-REROUTE]. In addition, any LSR compliant with this 285 draft must systematically include a node-id IPv4 or IPv6 subobject in 286 the RRO object for each protected TE LSP (in addition to the sub- 287 objects required by MPLS TE Fast Reroute as defined in [FAST-REROUTE]). 288 A node MAY decide to include its node-id subobject in the RRO object 289 only for the TE LSP whose IPv4 or IPv6 address source address 290 (specified in the SENDER-TEMPLATE object of the RSVP Path message) does 291 not belong to its local area/AS. 293 4. Processing RRO with node-id subobjects 295 The node-id subobject is added into the RECORD_ROUTE object after the 296 Label Record subobject. A node MUST not push a node-id subobject 297 without also pushing an IPv4 or IPv6 subobjects, as defined in [FAST- 298 REROUTE]. A node may push both IPv4 node-id and IPv6 node-id sub- 299 objects, but that MUST be done on consistent basis. 301 4.1. Finding Merge Point 303 A PLR can find the MP and suitable backup tunnel by simply comparing 304 the node-id of the backup tunnel's tail-end with Node IDs included in 305 the RRO of the primary tunnel. When both IPv4 node-id and IPv6 node-id 307 Vasseur, Ali and Sivabalan 6 309 draft-vasseur-mpls-nodeid-subobject-00.txt February 2003 311 sub-objects are present, a PLR may use any or both of them in finding 312 the MP address. 314 4.2. Processing at the border nodes 316 In a network with inter-AS traffic engineering, there may be some 317 concerns about leaking the RRO information, including node-id 318 subobjects, outside the autonomous system (see [INTER-AS-TE-REQS]). In 319 such cases, before forwarding the RRO object outside of an AS, the ASBR 320 may filter some/all node-id subobjects pertaining to the downstream 321 nodes in the AS. The RRO node-id subobjects filtration can be based on 322 a local policy configured on the ASBR. 324 How an ASBR handles/filters the contents of the RRO objects is outside 325 of the scope of this draft. 327 5. Backward Compatibility Note 329 To remain compatible with the nodes that do not support the RRO IPv4 or 330 IPv6 node-id subobjects, a node can safely ignore these objects. The 331 implication of this limitation will be that these nodes could not be MP 332 in a network with inter-area or inter-AS traffic engineering. 334 6. Security Considerations 336 This document does not introduce new security issues. The security 337 considerations pertaining to the original RSVP protocol [RSVP] remain 338 relevant. 340 7. Intellectual Property Considerations 342 Cisco Systems may have intellectual property rights claimed in regard 343 to some of the specification contained in this document 345 8. Acknowledgments 347 We would like to acknowledge input and helpful comments from Carol 348 Iturralde, Anca Zamfir, and Reshad Rahman. 350 References 351 [RSVP] Braden, et al, " Resource ReSerVation Protocol (RSVP) - Version 352 1, Functional Specification", RFC 2205, September 1997. 354 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 355 3209, December 2001. 357 Vasseur, Ali and Sivabalan 7 359 draft-vasseur-mpls-nodeid-subobject-00.txt February 2003 361 [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for 362 LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt, May 2003. 364 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 365 Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic- 366 09.txt(work in progress). 368 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", 369 draft-ietf-isis-traffic-04.txt (work in progress) 371 [MULTI-AREA-TE] Kompella at all,"Multi-area MPLS Traffic Engineering", 372 draft-kompella-mpls-multiarea-te-03.txt, June 2002. 374 [LOOSE-PATH-REOPT] Vasseur and Ikejiri, "Reoptimization of an explicit 375 loosely routed MPLS TE paths", draft-vasseur-mpls-loose-path-reopt- 376 00.txt, February 2003, Work in Progress. 378 [ABR-ASBR-FRR] Vasseur, Ali and Sivabalan, "Support of MPLS TE Fast 379 Reroute protection of ABR/ASBR LSRs", draft-vasseur-mpls-abr-asbr-frr 380 00.txt, February 2003, Work in progress. 382 [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering 383 requirements", draft-tewg-interas-te-req-01.txt (work in progress). 385 [INTER-AS-TE] Vasseur and Zhang, "MPLS Inter-AS Traffic Engineering", 386 draft-vasseur-mpls-inter-as-te-00.txt, February 2003, work in progress. 388 Authors' Address: 390 Jean Philippe Vasseur 391 Cisco Systems, Inc. 392 300 Apollo Drive 393 Chelmsford, MA 01824 394 USA 395 Email: jpv@cisco.com 397 Zafar Ali 398 Cisco Systems, Inc. 399 100 South Main St. #200 400 Ann Arbor, MI 48104 401 USA 402 zali@cisco.com 404 Siva Sivabalan 405 Cisco Systems, Inc. 406 2000 Innovation Drive 407 Kanata, Ontario, K2K 3E8 408 Canada 409 msiva@cisco.com 411 Vasseur, Ali and Sivabalan 8