idnits 2.17.1 draft-ietf-mpls-ldp-dod-00.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 04, 2012) is 4495 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I1' is mentioned on line 792, but not defined == Missing Reference: 'I' is mentioned on line 792, but not defined == Missing Reference: 'V' is mentioned on line 799, but not defined == Missing Reference: 'U2' is mentioned on line 799, but not defined == Missing Reference: 'Y' is mentioned on line 799, but not defined == Missing Reference: 'U' is mentioned on line 799, but not defined == Unused Reference: 'RFC4446' is defined on line 1238, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-mpls-ldp-ipv6-05 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-seamless-mpls-00 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Beckhaus 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Informational B. Decraene 5 Expires: July 7, 2012 France Telecom 6 K. Tiruveedhula 7 M. Konstantynowicz 8 Juniper Networks 9 L. Martini 10 Cisco Systems, Inc. 11 January 04, 2012 13 LDP Downstream-on-Demand in Seamless MPLS 14 draft-ietf-mpls-ldp-dod-00 16 Abstract 18 Seamless MPLS design enables a single IP/MPLS network to scale over 19 core, metro and access parts of a large packet network infrastructure 20 using standardized IP/MPLS protocols. One of the key goals of 21 Seamless MPLS is to meet requirements specific to access, including 22 high number of devices, their position in network topology and their 23 compute and memory constraints that limit the amount of state access 24 devices can hold.This can be achieved with LDP Downstream-on-Demand 25 (LDP DoD) label advertisement. This document describes LDP DoD use 26 cases and lists required LDP DoD procedures in the context of 27 Seamless MPLS design. 29 In addition, a new optional TLV type in the LDP label request message 30 is defined for fast-up convergence. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC2119 [RFC2119]. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on July 7, 2012. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Reference Topologies . . . . . . . . . . . . . . . . . . . . . 5 74 2.1. Access Topologies with Static Routing . . . . . . . . . . 6 75 2.2. Access Topologies with Access IGP . . . . . . . . . . . . 9 76 3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 11 77 3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 11 78 3.1.1. AN with Static Routing . . . . . . . . . . . . . . . . 11 79 3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . . 13 80 3.2. Service Provisioning and Activation . . . . . . . . . . . 13 81 3.3. Service Changes and Decommissioning . . . . . . . . . . . 16 82 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 16 83 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 17 84 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 17 85 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 17 86 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 18 87 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 19 88 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 19 89 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 20 90 4.1. LDP Label Distribution Control and Retention Modes . . . . 20 91 4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 21 92 4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22 93 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 22 94 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 22 95 4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 23 96 4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24 97 4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26 98 4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27 99 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27 100 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 101 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 106 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 109 1. Introduction 111 Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single 112 IP/MPLS network to scale over core, metro and access parts of a large 113 packet network infrastructure using standardized IP/MPLS protocols. 114 One of the key goals of Seamless MPLS is to meet requirements 115 specific to access, including high number of devices, their position 116 in network topology and their compute and memory constraints that 117 limit the amount of state access devices can hold. 119 In general MPLS routers implement either LDP or RSVP for MPLS label 120 distribution. The focus of this document is on LDP, as Seamless MPLS 121 design does not include a requirement for general purpose explicit 122 traffic engineering and bandwidth reservation. This document is 123 focusing on the unicast connectivity only. Multicast connectivity is 124 subject for further study. 126 In Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], IP/MPLS 127 protocol optimization is possible due to a relatively simple access 128 network topologies. Examples of such topologies involving access 129 nodes (AN) and aggregation nodes (AGN) include: 131 a. A single AN homed to a single AGN. 133 b. A single AN dual-homed to two AGNs. 135 c. Multiple ANs daisy-chained via a hub-AN to a single AGN. 137 d. Multiple ANs daisy-chained via a hub-AN to two AGNs. 139 e. Two ANs dual-homed to two AGNs. 141 f. Multiple ANs chained in a ring and dual-homed to two AGNs. 143 The amount of IP RIB and FIB state on ANs can be easily controlled in 144 the listed access topologies by using simple IP routing configuration 145 with either static routes or dedicated access IGP. Note that in all 146 of the above topologies AGNs act as the access border routers (access 147 ABRs) connecting the access topology to the rest of the network. 148 Hence in many cases it is sufficient for ANs to have a default route 149 pointing towards AGNs in order to achieve complete network 150 connectivity from ANs to the network. 152 The amount of MPLS forwarding state however requires additional 153 consideration. In general MPLS routers implement LDP Downstream 154 Unsolicited (LDP DU) label advertisement [RFC5036] and advertise MPLS 155 labels for all valid routes in their RIB. This is seen as a very 156 insufficient approach for ANs, as they only require a small subset of 157 the total routes (and associated labels) based on the required 158 connectivity for the provisioned services. And although filters can 159 be applied to those LDP DU labels advertisements, it is not seen as a 160 suitable tool to facilitate any-to-any AN-driven connectivity between 161 access and the rest of the MPLS network. 163 This document describes an access node driven "subscription model" 164 for label distribution in the access. The approach relies on the 165 standard LDP Downstream-on-Demand (LDP DoD) label advertisements as 166 specified in [RFC5036]. LDP DoD enables on-demand label distribution 167 ensuring that only required labels are requested, provided and 168 installed. 170 Note that LDP DoD implementation is not widely available in today's 171 IP/MPLS devices despite the fact that it has been described in the 172 LDP specification [RFC5036]. This is due to the fact that the 173 originally LDP DoD advertisement mode was aimed mainly at ATM and 174 Frame Relay MPLS implementations, where conserving label space used 175 on the links was essential for compatibility with ATM and Frame Relay 176 LSRs. 178 The following sections describe a set of reference access topologies 179 considered for LDP DoD usage and their associated IP routing 180 configurations, followed by LDP DoD use cases and LDP DoD procedures 181 in the context of Seamless MPLS design. 183 2. Reference Topologies 185 LDP DoD use cases are described in the context of a generic reference 186 end-to-end network topology based on Seamless MPLS design 187 [I-D.ietf-mpls-seamless-mpls] shown in Figure 1 188 +-------+ +-------+ +------+ +------+ 189 ---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN 190 +--------+/ +-------+ +-------+ +------+ +------+ 191 | Access | \/ \/ 192 | Network| /\ /\ 193 +--------+ +-------+ +-------+ +------+ +------+ 194 \---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN 195 +-------+ +-------+ +------+ +------+ 197 static routes 198 or access IGP ISIS L1 ISIS L2 199 <----Access----><--Aggregation Domain--><----Core-----> 200 <------------------------- MPLS ----------------------> 202 Figure 1: Seamless MPLS end-to-end reference network topology. 204 The access network is either single or dual homed to AGN1x, with 205 either a single or multiple parallel links to AGN1x. 207 Seamless MPLS access network topologies can range from a single- or 208 dual-homed access node to a chain or ring of access nodes, and use 209 either static routing or access IGP. The following sections describe 210 reference access topologies in more detail. 212 2.1. Access Topologies with Static Routing 214 In most cases access nodes connect to the rest of the network using 215 very simple topologies. Here static routing is sufficient to provide 216 the required IP connectivity. The following topologies are 217 considered for use with static routing and LDP DoD: 219 a. [I1] topology - a single AN homed to a single AGN. 221 b. [I] topology - multiple ANs daisy-chained to a single AGN. 223 c. [V] topology - a single AN dual-homed to two AGNs. 225 d. [U2] topology - two ANs dual-homed to two AGNs. 227 e. [Y] topology - multiple ANs daisy-chained to two AGNs. 229 The reference static routing and LDP configuration for [V] access 230 topology is shown in Figure 2. The same static routing and LDP 231 configuration also applies to [I1] topology. 233 +----+ +-------+ 234 |AN1 +------------------------+ AGN11 +------- 235 | +-------\ /-----------+ +-\ / 236 +----+ \ / +-------+ \ / 237 \/ \/ 238 /\ /\ 239 +----+ / \ +-------+ / \ 240 |AN2 +-------/ \-----------+ AGN12 +-/ \ 241 | +------------------------+ +------- 242 +----+ +-------+ 244 --(u)-> <-(d)-- 246 <----- static routing -------> <--- ISIS ---> 247 <-- LDP DU --> 248 <--------- LDP DoD ----------> <-- BGP LU --> 250 (u) static routes: 0/0 default, (optional) /32 or /128 destinations 251 (d) static routes: /32 or /128 AN loopbacks 253 Figure 2: [V] access topology with static routes. 255 In line with the Seamless MPLS design, static routes configured on 256 AGN1x and pointing towards the access network are redistributed in 257 either ISIS or BGP labeled unicast (BGP-LU) [RFC3107]. 259 The reference static routing and LDP configuration for [U2] access 260 topology is shown in Figure 3. 262 +----+ +-------+ 263 (d1) |AN1 +------------------------+ AGN11 +------- 264 | | + + +-\ / 265 v +-+--+ +-------+ \ / 266 | \/ 267 | /\ 268 ^ +-+--+ +-------+ / \ 269 | |AN2 + + AGN12 +-/ \ 270 (d2) | +------------------------+ +------- 271 +----+ +-------+ 273 --(u)-> <-(d)-- 275 <------- static routing --------> <--- ISIS ---> 276 <-- LDP DU --> 277 <----------- LDP DoD -----------> <-- BGP LU --> 279 (u) static route 0/0 default (/32 or /128 destinations optional) 280 (d) static route for /32 or /128 AN loopbacks 281 (d1) static route for /32 or /128 AN2 loopback and 0/0 default with lower preference 282 (d2) static route for /32 or /128 AN1 loopback and 0/0 default with lower preference 284 Figure 3: [U2] access topology with static routes. 286 The reference static routing and LDP configuration for [Y] access 287 topology is shown in Figure 4. The same static routing and LDP 288 configuration also applies to [I] topology. 290 +-------+ 291 | |---/ 292 /----+ AGN11 | 293 +----+ +----+ +----+ / | |---\ 294 | | | | | +----/ +-------+ 295 |ANn +...|AN2 +---+AN1 | 296 | | | | | +----\ +-------+ 297 +----+ +----+ +----+ \ | |---/ 298 \----+ AGN12 | 299 <-(d2)-- <-(d1)-- | |---\ 300 --(u)-> --(u)-> --(u)-> +-------+ 301 <-(d)-- 303 <------- static routing -------> <--- ISIS ---> 304 <-- LDP DU --> 305 <---------- LDP DoD -----------> <-- BGP LU --> 307 (u) static routes: 0/0 default, (optional) /32 or /128 destinations 308 (d) static routes: /32 or /128 AN loopbacks [1..n] 309 (d1) static routes: /32 or /128 AN loopbacks [2..n] 310 (d2) static routes: /32 or /128 AN loopbacks [3..n] 312 Figure 4: [Y] access topology with static routes. 314 Note that in all of the above topologies parallel ECMP (or L2 LAG) 315 links can be used between the nodes. 317 ANs support Inter-area LDP [RFC5283] in order to use the IP default 318 route to match the LDP FEC advertised by AGN1x and other ANs. 320 2.2. Access Topologies with Access IGP 322 A dedicated access IGP instance is used in the access network to 323 perform the internal routing between AGN1x and connected AN devices. 324 Example of such IGP could be ISIS, OSPFv2&v3, RIPv2&RIPng. This 325 access IGP instance is distinct from the IGP of the aggegation 326 domain. 328 The following topologies are considered for use with access IGP 329 routing and LDP DoD: 331 a. [U] topology - multiple ANs chained in an open ring and dual- 332 homed to two AGNs. 334 b. [Y] topology - multiple ANs daisy-chained via a hub-AN to two 335 AGNs. 337 The reference access IGP and LDP configuration for [U] access 338 topology is shown in Figure 5. 340 +-------+ 341 +-----+ +-----+ +----+ | +---/ 342 | AN3 |---| AN2 |---|AN1 +-----+ AGN11 | 343 +-----+ +-----+ +----+ | +---\ 344 . +-------+ 345 . 346 . +-------+ 347 +-----+ +-----+ +----+ | +---/ 348 |ANn-2|---|ANn-1|---|ANn +-----+ AGN12 | 349 +-----+ +-----+ +----+ | +---\ 350 +-------+ 352 <---------- access IGP ------------> <--- ISIS ---> 353 <-- LDP DU --> 354 <------------ LDP DoD -------------> <-- BGP LU --> 356 Figure 5: [U] access topology with access IGP. 358 The reference access IGP and LDP configuration for [Y] access 359 topology is shown in Figure 6. 361 +-------+ 362 | |---/ 363 /----+ AGN11 |2 364 +----+ +----+ +----+ / | |---\ 365 | | | | | +----/ +-------+ 366 |ANn +...|AN2 +---+AN1 | 367 | | | | | +----\ +-------+ 368 +----+ +----+ +----+ \ | |---/ 369 \----+ AGN12 | 370 | |---\ 371 +-------+ 373 <---------- access IGP ------------> <--- ISIS ---> 374 <-- LDP DU --> 375 <------------ LDP DoD -------------> <-- BGP LU --> 377 Figure 6: [Y] access topology with access IGP. 379 Note that in all of the above topologies parallel ECMP (or L2 LAG) 380 links can be used between the nodes. 382 In both of the above topologies, ANs (ANn ... AN1) and AGN1x share 383 the access IGP and advertise their IPv4 and IPv6 loopbacks and link 384 addresses. AGN1x advertise a default route into the access IGP. 386 ANs support Inter-area LDP [RFC5283] in order to use the IP default 387 route for matching the LDP FECs advertised by AGN1x or other ANs. 389 3. LDP DoD Use Cases 391 LDP DoD operation is driven by Seamless MPLS use cases. This section 392 illustrates these use cases focusing on services provisioned on the 393 access nodes and clarifies expected LDP DoD operation on the AN and 394 AGN1x devices. Two representative service types are used to 395 illustrate the service use cases: MPLS PWE3 [RFC4447] and BGP/MPLS 396 IPVPN [RFC4364]. 398 Described LDP DoD operations apply equally to all reference access 399 topologies described in Section 2. Operations that are specific to 400 certain access topologies are called out explicitly. 402 References to upstream and downstream nodes are made in line with the 403 definition of upstream and downstream LSR [RFC3031]. 405 This document is focusing on IPv4 LDP DoD procedures. Similar 406 procedures are required for IPv6 LDP DoD, however some extension 407 specific to IPv6 are likely to apply including LSP mapping, peer 408 discovery, transport connection establishment. These will be added 409 in this document once LDP IPv6 standardization is advanced as per 410 [I-D.ietf-mpls-ldp-ipv6]. 412 3.1. Initial Network Setup 414 An access node is commissioned without any services provisioned on 415 it. The AN may request labels for loopback addresses of any AN, AGN 416 or other nodes within Seamless MPLS network for operational and 417 management purposes. It is assumed that AGN1x has required IP/MPLS 418 configuration for network-side connectivity in line with Seamless 419 MPLS design [I-D.ietf-mpls-seamless-mpls]. 421 LDP sessions are configured between adjacent ANs and AGN1x using 422 their respective loopback addresses. 424 3.1.1. AN with Static Routing 426 If access static routing is used, ANs are provisioned with the 427 following static IP routing entries (topology references from 428 Section 2 are listed in square brackets): 430 a. [I1, V, U2] - Static default route 0/0 pointing to links 431 connected to AGN1x. Requires support for Inter-area LDP 432 [RFC5283]. 434 b. [U2] - Static /32 or /128 routes pointing to the other AN. Lower 435 preference static default route 0/0 pointing to links connected 436 to the other AN. Requires support for Inter-area LDP [RFC5283]. 438 c. [I, Y] - Static default route 0/0 pointing to links leading 439 towards AGN1x. Requires support for Inter-area LDP [RFC5283]. 441 d. [I, Y] - Static /32 or /128 routes to all ANs in the daisy-chain 442 pointing to links towards those ANs. 444 e. [I1, V, U2] - Optional - Static /32 or /128 routes for specific 445 nodes within Seamless MPLS network, pointing to links connected 446 to AGN1x. 448 f. [I, Y] - Optional - Static /32 or /128 routes for specific nodes 449 within the Seamless MPLS network, pointing to links leading 450 towards AGN1x. 452 Upstream AN/AGN1x should request labels over LDP DoD session(s) from 453 downstream AN/AGN1x for configured static routes if those static 454 routes are configured with LDP DoD request policy and if they are 455 pointing to a next-hop selected by routing. It is expected that all 456 configured /32 and /128 static routes to be used for LDP DoD are 457 configured with such policy on AN/AGN1x. 459 Downstream AN/AGN1x should respond to the label request from the 460 upstream AN/AGN1x with a label mapping (if requested route is present 461 in its RIB, and there is a valid label binding from its downstream), 462 and must install the advertised label as an incoming label in its 463 label table (LIB) and its forwarding table (LFIB). Upstream AN/AGN1x 464 must also install the received label as an outgoing label in their 465 LIB and LFIB. If the downstream AN/AGN1x does have the route present 466 in its RIB, but does not have a valid label binding from its 467 downstream, it should forward the request to its downstream. 469 In order to facilitate ECMP and IPFRR LFA local-repair, the upstream 470 AN/AGN1x must also send LDP DoD label requests to alternate next-hops 471 per its RIB, and install received labels as alternate entries in its 472 LIB and LFIB. 474 AGN1x node on the network side may use BGP labeled unicast [RFC3107] 475 in line with the Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. 476 In such a case AGN1x will be redistributing its static routes 477 pointing to local ANs into BGP labeled unicast to facilitate network- 478 to-access traffic flows. Likewise, to facilitate access-to-network 479 traffic flows, AGN1x will be responding to access-originated LDP DoD 480 label requests with label mappings based on its BGP labeled unicast 481 reachability for requested FECs. 483 3.1.2. AN with Access IGP 485 If access IGP is used, AN(s) advertise their loopbacks over the 486 access IGP with configured metrics. AGN1x advertise a default route 487 over the access IGP. 489 Similarly to the static route case, upstream AN/AGN1x should request 490 labels over LDP DoD session(s) from downstream AN/AGN1x for all /32 491 or /128 routes received over the access IGP. 493 Identically to the static route case, downstream AN/AGN1x should 494 respond to the label request from the upstream AN/AGN1x with a label 495 mapping (if the requested route is present in its RIB, and there is a 496 valid label binding from its downstream), and must install the 497 advertised label as an incoming label in its LIB and LFIB. Upstream 498 AN/AGN1x must also install the received label as an outgoing label in 499 their LIB and LFIB. 501 Identically to the static route case, in order to facilitate ECMP and 502 IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD 503 label requests to alternate next-hops per its RIB, and install 504 received labels as alternate entries in its LIB and LFIB. 506 AGN1x node on the network side may use BGP labeled unicast [RFC3107] 507 in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In 508 such case AGN1x will be redistributing routes received over the 509 access IGP (and pointing to local ANs), into BGP labeled unicast to 510 facilitate network-to-access traffic flows. Likewise, to facilitate 511 access-to-network traffic flows AGN1x will be responding to access 512 originated LDP DoD label requests with label mappings based on its 513 BGP labeled unicast reachability for requested FECs. 515 3.2. Service Provisioning and Activation 517 Following the initial setup phase described in Section 3.1, a 518 specific access node, referred to as AN*, is provisioned with a 519 network service. AN* relies on LDP DoD to request the required MPLS 520 LSP(s) label(s) from downstream AN/AGN1x node(s). Note that LDP DoD 521 operations are service agnostic, that is, they are the same 522 independently of the services provisioned on the AN*. 524 For illustration purposes two service types are described: MPLS PWE3 525 [RFC4447] service and BGP/MPLS IPVPN [RFC4364]. 527 MPLS PWE3 service - for description simplicity it is assumed that a 528 single segment pseudowire is signaled using targeted LDP FEC128 529 (0x80), and it is provisioned with the pseudowire ID and the loopback 530 IPv4 address of the destination node. The following IP/MPLS 531 operations need to be completed on the AN* to successfully establish 532 such PWE3 service: 534 a. LSP labels for destination /32 FEC (outgoing label) and the local 535 /32 loopback (incoming label) need to be signaled using LDP DoD. 537 b. Targeted LDP session over an associated TCP/IP connection needs 538 to be established to the PWE3 destination PE. This is triggered 539 by either an explicit targeted LDP session configuration on the 540 AN* or automatically at the time of provisioning the PWE3 541 instance. 543 c. Local and remote PWE3 labels for specific FEC128 PW ID need to be 544 signaled using targeted LDP and PWE3 signaling procedures 545 [RFC4447]. 547 d. Upon successful completion of the above operations, AN* programs 548 its RIB/LIB and LFIB tables, and activates the MPLS PWE3 service. 550 Note - only minimum operations applicable to service connectivity 551 have been listed. Other non IP/MPLS connectivity operations that may 552 be required for successful service provisioning and activation are 553 out of scope in this document. 555 BGP/MPLS IPVPN service - for description simplicity it is assumed 556 that AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4 for 557 short) [RFC4364]. The following IP/MPLS operations need to be 558 completed on the AN* to successfully establish VPNv4 service: 560 a. BGP peering sessions with associated TCP/IP connections need to 561 be established with the remote destination VPNv4 PEs or Route 562 Reflectors. 564 b. Based on configured BGP policies, VPNv4 BGP NLRIs need to be 565 exchanged between AN* and its BGP peers. 567 c. Based on configured BGP policies, VPNv4 routes need to be 568 installed in the AN* VRF RIB and FIB, with corresponding BGP 569 next-hops. 571 d. LSP labels for destination BGP next-hop /32 FEC (outgoing label) 572 and the local /32 loopback (incoming label) need to be signaled 573 using LDP DoD. 575 e. Upon successful completion of above operations, AN* programs its 576 RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN 577 service. 579 Note - only minimum operations applicable to service connectivity 580 have been listed. Other non IP/MPLS connectivity operations that may 581 be required for successful service provisioning are out of scope in 582 this document. 584 To establish an LSP for destination /32 FEC for any of the above 585 services, AN* looks up its local routing table for a matching route, 586 selects the best next-hop(s) and associated outgoing link(s). 588 If a label for this /32 FEC is not already installed based on the 589 configured static route with LDP DoD request policy or access IGP RIB 590 entry, AN* must send an LDP DoD label mapping request. Downstream 591 AN/AGN1x LSR(s) checks its RIB for presence of the requested /32 and 592 associated valid outgoing label binding, and if both are present, 593 replies with its label for this FEC and installs this label as 594 incoming in its LIB and LFIB. Upon receiving the label mapping the 595 AN* must accept this label based on the exact route match of 596 advertised FEC and route entry in its RIB or based on the longest 597 match in line with Inter-area LDP [RFC5283]. If the AN* accepts the 598 label it must install it as an outgoing label in its LIB and LFIB. 600 In access topologies [V] and [Y], if AN* is dual homed to two AGN1x 601 and routing entries for these AGN1x are configured as equal cost 602 paths, AN* must send LDP DoD label requests to both AGN1x devices and 603 install all received labels in its LIB and LFIB. 605 In order for AN* to implement IPFRR LFA local-repair, AN* must also 606 send LDP DoD label requests to alternate next-hops per its RIB, and 607 install received labels as alternate entries in its LIB and LFIB. 609 When forwarding PWE3 or VPNv4 packets AN* chooses the LSP label based 610 on the locally configured static /32 or default route, or default 611 route signaled via access IGP. If a route is reachable via multiple 612 interfaces to AGN1x nodes and the route has multiple equal cost 613 paths, AN* must implement Equal Cost Multi-Path (ECMP) functionality. 614 This involves AN* using hash-based load-balancing mechanism and 615 sending the PWE3 or VPNv4 packets in a flow-aware manner with 616 appropriate LSP labels via all equal cost links. 618 ECMP mechanism is applicable in an equal manner to parallel links 619 between two network elements and multiple paths towards the 620 destination. The traffic demand is distributed over the available 621 paths. 623 AGN1x node on the network side may use BGP labeled unicast [RFC3107] 624 in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In 625 such case AGN1x will be redistributing its static routes (or routes 626 received from the access IGP) pointing to local ANs into BGP labeled 627 unicast to facilitate network-to-access traffic flows. Likewise, to 628 facilitate access-to-network traffic flows AGN1x will be responding 629 to access originated LDP DoD label requests with label mappings based 630 on its BGP labeled unicast reachability for requested FECs. 632 3.3. Service Changes and Decommissioning 634 Whenever AN* service gets decommissioned or changed and connectivity 635 to specific destination is not longer required, the associated MPLS 636 LSP label resources should be released on AN*. 638 MPLS PWE3 service - if the PWE3 service gets decommissioned and it is 639 the last PWE3 to a specific destination node, the targeted LDP 640 session is not longer needed and should be terminated (automatically 641 or by configuration). The MPLS LSP(s) to that destination is no 642 longer needed either. 644 BGP/MPLS IPVPN service - deletion of a specific VPNv4 (VRF) instance, 645 local or remote re-configuration may result in specific BGP next- 646 hop(s) being no longer needed. The MPLS LSP(s) to that destination 647 is no longer needed either. 649 In all of the above cases the following LDP DoD related operations 650 apply: 652 o If the /32 FEC label for the aforementioned destination node was 653 originally requested based on either tLDP session configuration 654 and default route or required BGP next-hop and default route, AN* 655 should delete the label from its LIB and LFIB, and release it from 656 downstream AN/AGN1x by using LDP DoD procedures. 658 o If the /32 FEC label was originally requested based on the static 659 /32 route configuration with LDP DoD request policy, the label 660 must be retained by AN*. 662 3.4. Service Failure 664 A service instance may stop being operational due to a local or 665 remote service failure event. 667 In general, unless the service failure event modifies required MPLS 668 connectivity, there should be no impact on the LDP DoD operation. 670 If the service failure event does modify the required MPLS 671 connectivity, LDP DoD operations apply as described in Section 3.2 672 and Section 3.3. 674 3.5. Network Transport Failure 676 A number of different network events can impact services on AN*. The 677 following sections describe network event types that impact LDP DoD 678 operation on AN and AGN1x nodes. 680 3.5.1. General Notes 682 If service on any of the ANs is affected by any network failure and 683 there is no network redundancy, the service must go into a failure 684 state. When the network failure is recovered from, the service must 685 be re-established automatically. 687 The following additional LDP-related functions should be supported to 688 comply with Seamless MPLS [I-D.ietf-mpls-seamless-mpls] fast service 689 restoration requirements as follows: 691 a. Local-repair - AN and AGN1x should support local-repair for 692 adjacent link or node failure for access-to-network, network-to- 693 access and access-to-access traffic flows. Local-repair should 694 be implemented by using either IPFRR LDP LFA, simple ECMP or 695 primary/backup switchover upon failure detection. 697 b. LDP session protection - LDP sessions should be configured with 698 LDP session protection to avoid delay upon the recovery from link 699 failure. LDP session protection ensures that FEC label binding 700 is maintained in the control plane as long as LDP session stays 701 up. 703 c. IGP-LDP synchronization - If access IGP is used, LDP sessions 704 between ANs, and between ANs and AGN1x, should be configured with 705 IGP-LDP synchronization to avoid unnecessary traffic loss in case 706 the access IGP converged before LDP and there is no LDP label 707 binding to the downstream best next-hop. 709 3.5.2. AN Node Failure 711 AN node fails and all links to adjacent nodes go down. 713 Adjacent AN/AGN1x nodes remove all routes pointing to the failed 714 link(s) from their RIB tables (including /32 loopback belonging to 715 the failed AN and any other routes reachable via the failed AN). 716 This in turn triggers the removal of associated outgoing /32 FEC 717 labels from their LIB and LFIB tables. 719 If access IGP is used, the AN node failure will be propagated via IGP 720 link updates across the access topology. 722 If a specific /32 FEC(s) is not reachable anymore from those AN/ 723 AGN1x, they must also send LDP label withdraw to their upstream LSRs 724 to notify about the failure, and remove the associated incoming 725 label(s) from their LIB and LFIB tables. Upstream LSRs upon 726 receiving label withdraw should remove the signaled labels from their 727 LIB/LFIB tables, and propagate LDP label withdraw across their 728 upstream LDP DoD sessions. 730 In [U] topology there may be an alternative path to routes previously 731 reachable via the failed AN node. In this case adjacent AN/AGN1x 732 should invoke local-repair (IPFRR LFA, ECMP) and switchover to 733 alternate next-hop to reach those routes. 735 AGN1x gets notified about the AN failure via either access IGP (if 736 used) and/or cascaded LDP DoD label withdraw(s). AGN1x must 737 implement all relevant global-repair IP/MPLS procedures to propagate 738 the AN failure towards the core network. This should involve 739 removing associated routes (in access IGP case) and labels from its 740 LIB and LFIB tables, and propagating the failure on the network side 741 using BGP-LU and/or core IGP/LDP-DU procedures. 743 Upon AN coming back up, adjacent AN/AGN1x nodes automatically add 744 routes pointing to recovered links based on the configured static 745 routes or access IGP adjacency and link state updates. This should 746 be then followed by LDP DoD label signaling and subsequent binding 747 and installation of labels in LIB and LFIB tables. 749 3.5.3. AN/AGN Link Failure 751 Depending on the access topology and the failed link location 752 different cases apply to the network operation after AN link failure 753 (topology references from Section 2 in square brackets): 755 a. [all] - link failed, but at least one ECMP parallel link remains 756 - nodes on both sides of the failed link must stop using the 757 failed link immediately (local-repair), and keep using the 758 remaining ECMP parallel links. 760 b. [I1, I, Y] - link failed, and there are no ECMP or alternative 761 links and paths - nodes on both sides of the failed link must 762 remove routes pointing to the failed link immediately from the 763 RIB, remove associated labels from their LIB and LFIB tabels, and 764 must send LDP label withdraw(s) to their upstream LSRs. 766 c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate 767 path remains - AN/AGN1x node must stop using the failed link and 768 immediately switchover (local-repair) to the remaining ECMP path 769 or alternate path. AN/AGN1x must remove affected next-hops and 770 labels from its tables and invoke LDP label withdraw as per point 771 (a) above. If there is an AGN1x node terminating the failed 772 link, it must remove routes pointing to the failed link 773 immediately from the RIB, remove associated labels from their LIB 774 and LFIB tabels, and must propagate the failure on the network 775 side using BGP-LU and/or core IGP procedures. 777 If access IGP is used AN/AGN1x link failure will be propagated via 778 IGP link updates across the access topology. 780 LDP DoD will also propagate the link failure by sending label 781 withdraws to upstream AN/AGN1x nodes, and label release messages 782 downstream AN/AGN1x nodes. 784 3.5.4. AGN Node Failure 786 AGN1x fails and all links to adjacent access nodes go down. 788 Depending on the access topology, following cases apply to the 789 network operation after AGN1x node failure (topology references from 790 Section 2 in square brackets): 792 a. [I1, I] - ANs are isolated from the network - AN adjacent to the 793 failure must remove routes pointing to the failed AGN1x node 794 immediately from the RIB, remove associated labels from their LIB 795 and LFIB tabels, and must send LDP label withdraw(s) to their 796 upstream LSRs. If access IGP is used, an IGP link update should 797 be sent. 799 b. [U2, U, V, Y] - at least one ECMP or alternate path remains - AN 800 adjacent to failed AGN1x must stop using the failed link and 801 immediately switchover (local-repair) to the remaining ECMP path 802 or alternate path. AN must remove affected routes and labels 803 from its tables and invoke LDP label withdraw as per point (a) 804 above. 806 Network side procedures for handling AGN1x node failure have been 807 described in Seamless MPLS [I-D.ietf-mpls-seamless-mpls]. 809 3.5.5. AGN Network-side Reachability Failure 811 AGN1x loses network reachability to a specific destination or set of 812 network-side destinations. 814 In such event AGN1x must send LDP Label Withdraw messages to its 815 upstream ANs, withdrawing labels for all affected /32 FECs. Upon 816 receiving those messages ANs must remove those labels from their LIB 817 and LFIB tables, and use alternative LSPs instead if available as 818 part of global-repair. In turn ANs should also sent Label Withdraw 819 messages for affected /32 FECs to their upstream ANs. 821 If access IGP is used, and AGN1x gets completely isolated from the 822 core network, it should stop advertising the default route 0/0 into 823 the access IGP. 825 4. LDP DoD Procedures 827 Label Distribution Protocol is specified in [RFC5036], and all LDP 828 Downstream-on-Demand implementations MUST follow this specification. 830 In the MPLS architecture [RFC3031], network traffic flows from 831 upstream to downstream LSR. The use cases in this document rely on 832 the downstream assignment of labels, where labels are assigned by the 833 downstream LSR and signaled to the upstream LSR as shown in Figure 7. 835 +----------+ +------------+ 836 | upstream | | downstream | 837 ------+ LSR +------+ LSR +---- 838 traffic | | | | address 839 source +----------+ +------------+ (/32 for IPv4) 840 traffic 841 label distribution for IPv4 FEC destination 842 <------------------------- 844 traffic flow 845 -------------------------> 847 Figure 7: LDP label assignment direction 849 4.1. LDP Label Distribution Control and Retention Modes 851 LDP protocol specification [RFC5036] defines two modes for label 852 distribution control, following the definitions in MPLS architecture 853 [RFC3031]: 855 o Independent mode - an LSR recognizes a particular FEC and makes a 856 decision to bind a label to the FEC independently from 857 distributing that label binding to its label distribution peers. 858 A new FEC is recognized whenever a new route becomes valid on the 859 LSR. 861 o Ordered mode - an LSR binds a label to a particular FEC if it is 862 the egress router for that FEC or if it has already received a 863 label binding for that FEC from its next-hop LSR for that FEC. 865 Using independent label distribution control with LDP DoD and access 866 static routing will prevent the access LSRs from propagating label 867 binding failure along the access topology, making it impossible to 868 switchover to an alternate path, even if such a path exists. 870 LDP protocol specification [RFC5036] defines two modes for label 871 retention, following the definitions in MPLS architecture [RFC3031]: 873 o Liberal mode - LSR retains every label mappings received from a 874 peer LSR, regardless of whether the peer LSR is the next-hop for 875 the advertised mapping. This mode allows for quicker adaptation 876 to routing changes. 878 o Conservative mode - LSR retains advertised label mappings only if 879 they will be used to forward packets, that is only if they are 880 received from a valid next-hop LSR according to routing. This 881 mode allows LSR to maintain fewer labels, but slows down LSR 882 adaptation to routing changes. 884 Using conservative label retention mode with LDP DoD will prevent the 885 access LSRs (AN and AGN1x nodes) from implementing IPFRR LFA 886 alternate based local-repair, as label mapping request can not be 887 sent to alternate next-hops. 889 Adhering to the overall design goals of Seamless MPLS 890 [I-D.ietf-mpls-seamless-mpls], specifically achieving a large network 891 scale without compromising fast service restoration, all access LSRs 892 (AN and AGN1x nodes) MUST use LDP DoD advertisement mode with: 894 o Ordered label distribution control - enables propagation of label 895 binding failure within the access topology. 897 o Liberal label retention - enables pre-programming of alternate 898 next-hops with associated FEC labels. 900 In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an 901 access ABR connecting access and metro domains. To enable failure 902 propagation between those domains, access ABR MUST implement ordered 903 label distribution control when redistributing access static routes 904 and/or access IGP routes into the network-side BGP labeled unicast 905 [RFC3107] or core IGP with LDP Downstream Unsolicited label 906 advertisement. 908 4.2. IPv6 Support 910 Current LDP protocol specification [RFC5036] defines procedures and 911 messages for exchanging FEC-label bindings over IPv4 and/or IPv6 912 networks. However number of IPv6 usage areas are not clearly 913 specified including: packet to LSP mapping for IPv6 destination 914 router, no IPv6 specific LSP identifier, no LDP discovery using IPv6 915 multicast address, separate LSPs for IPv4 and IPv6, and others. 917 All of these issues and more are being addressed by 918 [I-D.ietf-mpls-ldp-ipv6] that will update LDP protocol specification 919 [RFC5036] in respect to the IPv6 usage. For the future deployment, 920 LDP DoD use case and procedures described in this document SHOULD 921 also support IPv6 for transport and services. 923 4.3. LDP DoD Session Negotiation 925 Access LSR/ABR should propose the Downstream-on-Demand label 926 advertisement by setting "A" value to 1 in the Common Session 927 Parameters TLV of the Initialization message. The rules for 928 negotiating the label advertisement mode are specified in LDP 929 protocol specification [RFC5036]. 931 To establish a Downstream-on-Demand session between the two access 932 LSR/ABRs, both should propose the Downstream-on-Demand label 933 advertisement mode in the Initialization message. If the access LSR 934 only supports LDP DoD and the access ABR proposes Downstream 935 Unsolicited mode, the access LSR SHOULD send a Notification message 936 with status "Session Rejected/Parameters Advertisement Mode" and then 937 close the LDP session as specified in LDP protocol specification 938 [RFC5036]. 940 If an access LSR is acting in an active role, it should re-attempt 941 the LDP session immediately. If the access LSR receives the same 942 Downstream Unsolicited mode again, it should follow the exponential 943 backoff algorithm as defined in the LDP protocol specification 944 [RFC5036] with delay of 15 seconds and subsequent delays growing to a 945 maximum delay of 2 minutes. 947 In case a PWE3 service is required between the adjacent access LSR/ 948 ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same 949 LDP session should be used for PWE3 FECs. Even if LDP DoD label 950 advertisement has been negotiated for IPv4 and IPv6 LDP FECs as 951 described earlier, LDP session should use Downstream Unsolicited 952 label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. 954 4.4. Label Request Procedures 956 4.4.1. Access LSR/ABR Label Request 958 Upstream access LSR/ABR will request label bindings from adjacent 959 downstream access LSR/ABR based on the following trigger events: 961 a. Access LSR/ABR is configured with /32 static route with LDP DoD 962 label request policy in line with intitial network setup use case 963 described in Section 3.1. 965 b. Access LSR/ABR is configured with a service in line with service 966 use cases described in Section 3.2 and Section 3.3. 968 c. Access LSR/ABR link to adjacent node comes up and LDP DoD session 969 is established. In this case access LSR should send label 970 request messages for all /32 static routes configured with LDP 971 DoD policy and all /32 routes related to provisioned services 972 that are not covered by default route. In line with use cases 973 described in Section 3.5. 975 d. In all above cases requests MUST be sent to next-hop LSR(s) and 976 alternate LSR(s). 978 Downstream access LSR/ABR will respond with label mapping message 979 with a non-null label if any of the below conditions are met: 981 a. Downstream access LSR/ABR - requested FEC is an IGP or static 982 route and there is an LDP label already learnt from the next- 983 next-hop downstream LSR (by LDP DoD or LDP DU). If there is no 984 label for the requested FEC and there is an LDP DoD session to 985 the next-next-hop downstream LSR, downstream LSR MUST send a 986 label request message for the same FEC to the next-next-hop 987 downstream LSR. In such case downstream LSR will respond back to 988 the requesting upstream access LSR only after getting a label 989 from the next-next-hop downstream LSR peer. 991 b. Downstream access ABR only - requested FEC is a BGP labelled 992 unicast route [RFC3107] and this BGP route is the best selected 993 for this FEC. 995 Downstream access LSR/ABR may respond with a label mapping with 996 explicit-null or implicit-null label if it is acting as an egress for 997 the requested FEC, or it may respond with "No Route" notification if 998 no route exists. 1000 4.4.2. Label Request Retry 1002 If an access LSR/ABR receives a "No route" Notification in response 1003 to its label request message, it should retry using an exponential 1004 backoff algorithm similar to the backoff algoritm mentioned in the 1005 LDP session negotiation described in Section 4.3. 1007 If there is no response to the sent label request message, the LDP 1008 specification [RFC5036] (section A.1.1, page# 100) states that the 1009 LSR should not send another request for the same label to the peer 1010 and mandates that a duplicate label request is considered a protocol 1011 error and should be dropped by the receiving LSR by sending a 1012 Notification message. 1014 Thus, if there is no response from the downstream peer, the access 1015 LSR/ABR should not send a duplicate label request message again. 1017 If the static route corresponding to the FEC gets deleted or if the 1018 DoD request policy is modified to reject the FEC before receiving the 1019 label mapping message, then the access LSR/ABR should send a Label 1020 Abort message to the downstream LSR. 1022 4.4.3. Label Request with Fast-Up Convergence 1024 In some conditions, the exponential backoff algorithm usage described 1025 in Section 4.4.2 may result in a longer than desired wait time to get 1026 a successful LDP label to route mapping. An example is when a 1027 specific route is unavailable on the downstream LSR when the label 1028 mapping request from the upstream is received, but later comes back. 1029 In such case using the exponential backoff algorithm may result in a 1030 max delay wait time before the upstream LSR sends another LDP label 1031 request. 1033 Fast-up convergence can be addressed with a minor extension to the 1034 LDP DoD procedure, as described in this section. The downstream and 1035 upstream LSRs SHOULD implement this extension if up convergence 1036 improvement is desired. 1038 The extension consists of the upstream LSR indicating to the 1039 downstream LSR that the label request should be queued on the 1040 downstream LSR until the requested route is available. 1042 To implement this behavior, a new Optional Parameter is defined for 1043 use in the Label Request message: 1045 Optional Parameter Length Value 1046 Queue Request TLV 0 see below 1048 0 1 2 3 1049 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 |1|0| Queue Request (0x????) | Length (0x00) | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 U-bit = 1 1055 Unknown TLV bit is set to 1. If this optional TLV is unknown, 1056 it should be ignored without sending "no route" notification. 1057 Ensures backward compatibility. 1059 F-bit = 0 1060 Forward unknown TLV bit is set to 0. The unknown TLV is not 1061 forwarded. 1063 Type 1064 Queue Request Type value to be allocated by IANA. 1066 Length = 0x00 1067 Specifies the length of the Value field in octets. 1069 The operation is as follows. 1071 To benefit from the fast-up convergence improvement, the upstream LSR 1072 sends a Label Request message with a Queue Request TLV. 1074 If the downstream LSR supports the Queue Request TLV, it verifies if 1075 route is available and if so it replies with label mapping as per 1076 existing LDP procedures. 1078 If the route is not available, the downstream LSR queues the request 1079 and replies as soon as the route becomes available. In the meantime, 1080 it does not send a "no route" notification back. When sending a 1081 label request with the Queue Request TLV, the upstream LSR does not 1082 retry the Label Request message if it does not receive a reply from 1083 its downstream peer 1085 If the upstream LSR wants to abort an outstanding label request while 1086 the Label Request is queued in the downstream LSR, the upstream LSR 1087 sends a Label Abort Request message, making the downstream LSR to 1088 remove the original request from the queue and send back a 1089 notification Label Request Aborted [RFC5036]. 1091 If the downstream LSR does not support the Queue Request TLV, it will 1092 silently ignores it, and sends a "no route" notification back. In 1093 this case the upstream LSR invokes the exponential backoff algorithm 1094 described in Section 4.4.2. 1096 This described procedure ensures backward compatitibility. 1098 4.5. Label Withdraw 1100 If an MPLS label on the downstream access LSR/ABR is no longer valid, 1101 the downstream access LSR/ABR withdraws this FEC/label binding from 1102 the upstream access LSR/ABR with the Label Withdraw Message [RFC5036] 1103 with a specified label TLV or with an empty label TLV. 1105 Downstream access LSR/ABR SHOULD withdraw a label for specific FEC in 1106 the following cases: 1108 a. If LDP DoD ingress label is associated with an outgoing label 1109 assigned by BGP labelled unicast route, and this route is 1110 withdrawn. 1112 b. If LDP DoD ingress label is associated with an outgoing label 1113 assigned by LDP (DoD or DU) and the IGP route is withdrawn from 1114 the RIB or downstream LDP session is lost. 1116 c. If LDP DoD ingress label is associated with an outgoing label 1117 assigned by LDP (DoD or DU) and the outgoing label is withdrawn 1118 by the downstream LSR. 1120 d. If LDP DoD ingress label is associated with an outgoing label 1121 assigned by LDP (DoD or DU), route next-hop changed and 1123 * there is no LDP session to the new next-hop. To minimize 1124 probability of this, the access LSR/ABR should implement LDP- 1125 IGP synchronization procedures as specified in [RFC5443]. 1127 * there is an LDP session but no label from downstream LSR. See 1128 note below. 1130 e. If access LSR/ABR is configured with a policy to reject exporting 1131 label mappings to upstream LSR. 1133 The upstream access LSR/ABR responds to the Label Withdraw Message 1134 with the Label Release Message [RFC5036]. 1136 After sending label release message to downstream access LSR/ABR, the 1137 upstream access LSR/ABR should resend label request message, assuming 1138 upstream access LSR/ABR still requires the label. 1140 Downstream access LSR/ABR should withdraw a label if the local route 1141 configuration (e.g. /32 loopback) is deleted. 1143 Note: For any events inducing next hop change, downstream access LSR/ 1144 ABR should attempt to converge the LSP locally before withdrawing the 1145 label from an upstream access LSR/ABR. For example if the next-hop 1146 changes for a particular FEC and if the new next-hop allocates labels 1147 by LDP DoD session, then the downstream access LSR/ABR must send a 1148 label request on the new next-hop session. If downstream access LSR/ 1149 ABR doesn't get label mapping for some duration, then and only then 1150 downstream access LSR/ABR must withdraw the upstream label. 1152 4.6. Label Release 1154 If an access LSR/ABR does not need any longer a label for a FEC, it 1155 sends a Label Release Message [RFC5036] to the downstream access LSR/ 1156 ABR with or without the label TLV. 1158 If upstream access LSR/ABR receives an unsolicited label mapping on 1159 DoD session, they should release the label by sending label release 1160 message. 1162 Access LSR/ABR should send a label release message to the downstream 1163 LSR in the following cases: 1165 a. If it receives a label withdraw from the downstream access LSR/ 1166 ABR. 1168 b. If the /32 static route with LDP DoD label request policy is 1169 deleted. 1171 c. If the service gets decommissioned and there is no corresponding 1172 /32 static route with LDP DoD label request policy configured. 1174 d. If the route next-hop changed, and the label does not point to 1175 the best or alternate next-hop. 1177 e. If it receives a label withdraw from a downstream DoD session. 1179 4.7. Local Repair 1181 To support local-repair with ECMP and IPFRR LFA, access LSR/ABR MUST 1182 request labels on both best next-hop and alternate next-hop LDP DoD 1183 sessions as specified in the label request procedures in Section 4.4. 1184 This will enable access LSR/ABR to pre-program the alternate 1185 forwarding path with the alternate label(s), and invoke IPFRR LFA 1186 switch-over procedure if the primary next-hop link fails. 1188 5. IANA Considerations 1189 5.1. LDP TLV TYPE 1191 This document uses a new a new Optional Parameter Queue Request TLV 1192 in the Label Request message defined in Section 4.4.3. IANA already 1193 maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by 1194 RFC5036. The following value is suggested for assignment: 1196 TLV type Description 1197 0x0971 Queue Request TLV 1199 6. Security Considerations 1201 7. Acknowledgements 1203 The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai 1204 Leymann and Ina Minei for their suggestions and review. 1206 8. References 1208 8.1. Normative References 1210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1211 Requirement Levels", BCP 14, RFC 2119, March 1997. 1213 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1214 Specification", RFC 5036, October 2007. 1216 8.2. Informative References 1218 [I-D.ietf-mpls-ldp-ipv6] 1219 Asati, R., Manral, V., Papneja, R., and C. Pignataro, 1220 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-05 1221 (work in progress), August 2011. 1223 [I-D.ietf-mpls-seamless-mpls] 1224 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 1225 M., and D. Steinberg, "Seamless MPLS Architecture", 1226 draft-ietf-mpls-seamless-mpls-00 (work in progress), 1227 May 2011. 1229 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1230 Label Switching Architecture", RFC 3031, January 2001. 1232 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 1233 BGP-4", RFC 3107, May 2001. 1235 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1236 Networks (VPNs)", RFC 4364, February 2006. 1238 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1239 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1241 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1242 Heron, "Pseudowire Setup and Maintenance Using the Label 1243 Distribution Protocol (LDP)", RFC 4447, April 2006. 1245 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 1246 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 1247 July 2008. 1249 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 1250 Synchronization", RFC 5443, March 2009. 1252 Authors' Addresses 1254 Thomas Beckhaus 1255 Deutsche Telekom AG 1256 Heinrich-Hertz-Strasse 3-7 1257 Darmstadt, 64307 1258 Germany 1260 Phone: +49 6151 58 12825 1261 Fax: 1262 Email: thomas.beckhaus@telekom.de 1263 URI: 1265 Bruno Decraene 1266 France Telecom 1267 38-40 rue du General Leclerc 1268 Issy Moulineaux cedex 9, 92794 1269 France 1271 Phone: 1272 Fax: 1273 Email: bruno.decraene@orange.com 1274 URI: 1276 Kishore Tiruveedhula 1277 Juniper Networks 1278 10 Technology Park Drive 1279 Westford, Massachusetts 01886 1280 USA 1282 Phone: 1-(978)-589-8861 1283 Fax: 1284 Email: kishoret@juniper.net 1285 URI: 1287 Maciek Konstantynowicz 1288 Juniper Networks 1290 Phone: 1291 Fax: 1292 Email: maciek@juniper.net 1293 URI: 1295 Luca Martini 1296 Cisco Systems, Inc. 1297 9155 East Nichols Avenue, Suite 400 1298 Englewood, CO 80112 1299 USA 1301 Phone: 1302 Fax: 1303 Email: lmartini@cisco.com 1304 URI: