idnits 2.17.1 draft-ietf-mpls-ldp-igp-sync-bcast-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 3) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([LDP-IGP-SYNC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 22, 2010) is 5121 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) == Unused Reference: 'LDP' is defined on line 301, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5443 (ref. 'LDP-IGP-SYNC') Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Kini (Ed) 3 Internet Draft W. Lu (Ed) 4 Intended status: Standards Track Ericsson 5 Expires: September 2010 March 22, 2010 7 LDP IGP Synchronization for broadcast networks 8 draft-ietf-mpls-ldp-igp-sync-bcast-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on September 22, 2010. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided 47 without warranty as described in the Simplified BSD License. 49 Abstract 51 LDP IGP Synchronization ([LDP-IGP-SYNC]) describes a mechanism to 52 prevent black-holing traffic (e.g. VPN) when an interior gateway 53 protocol (IGP) is operational on a link but Label Distribution 54 Protocol (LDP) is not. If this mechanism is applied to broadcast 55 links that have more than one LDP/IGP peer, the cost-out 56 procedure can only be applied to the link as a whole but not an 57 individual peer. When a new LDP peer comes up on a broadcast 58 network, this can result in loss of traffic through other 59 established peers on that network. This document describes a 60 mechanism to address that use-case without dropping traffic. The 61 mechanism does not introduce any protocol changes. 63 Table of Contents 65 1. Introduction ..................................................2 66 2. Conventions used in this document .............................3 67 3. Problem Statement .............................................4 68 4. Solution ......................................................5 69 5. Scope .........................................................7 70 6. Applicability .................................................7 71 7. Security Considerations .......................................7 72 8. IANA Considerations ...........................................7 73 9. Conclusion ....................................................7 74 10. References ...................................................8 75 10.1. Normative References ....................................8 76 10.2. Informative References ..................................8 77 11. Acknowledgments ..............................................8 78 Appendix A. Computation of 'cut-edge' ............................9 79 Appendix B. Sync without support at one end .....................10 81 1. Introduction 83 In [LDP-IGP-SYNC], when LDP is not fully operational on a link, 84 the IGP advertises the link with maximum cost to avoid any 85 transit traffic on the link if possible. When LDP becomes 86 operational i.e., all the label bindings have been exchanged, the 87 link is advertised with its correct cost. This tries to ensure 88 that all along the IGP shortest path, the LDP LSP is available. 90 The mechanisms in [LDP-IGP-SYNC] have limitations when applied to 91 a broadcast link. These are described in section 3. A solution is 92 defined in section 4. 94 2. Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 97 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in 99 [RFC2119]. 101 3. Problem Statement 103 On broadcast networks, a router's link-state advertisement (LSA) 104 contains a single cost to the broadcast network, rather than a 105 separate cost to each peer on the broadcast network. The 106 operation of the mechanism in [LDP-IGP-SYNC] is analyzed using 107 the sample topology of Figure 1 below where routers A, B, C and E 108 are attached to a common broadcast network. Say all links in that 109 topology have a cost of 1 except the link A-PE3 that has a cost 110 of 10. The use-case when router B's link to the broadcast network 111 comes up is analyzed. Before that link comes up, traffic between 112 PE1 and PE2 flows along the bi-directional path PE1-A-C 113 -D-PE2 and traffic between PE1 and PE3 flows along the bi- 114 directional path PE1-A-E-PE3. 116 | 117 | +---+ +---+ 118 |----| B |-----------|PE2| 119 | +---+ +---+ 120 +---+ +---+ | | 121 |PE1|----| A |----| | 122 +---+ +---+ | | 123 | | +---+ +---+ | 124 | |----| C |----| D |----+ 125 | | +---+ +---+ 126 | | 127 | | 128 | | 129 | | +---+ 130 | |----| E |-------------+ 131 | | +---+ | 132 | | | 133 | | 134 | +---+ 135 +---------------------------|PE3| 136 +---+ 138 Figure 1 LDP IGP Sync on a broadcast network 140 In one interpretation of the applicability of [LDP-IGP-SYNC] to 141 broadcast networks, when a new router is discovered on a 142 broadcast network, that network should avoid transit traffic till 143 LDP becomes operational between all routers on that network. This 144 can be achieved by having all the attached routers advertise 145 maximum cost to that network. This should result in traffic that 146 is being sent via that broadcast network to be diverted. However, 147 traffic might be inadvertently diverted to the link that just 148 came up. Till LDP becomes operational, that traffic will be 149 black-holed. An additional problem is route churn in the entire 150 network that results in traffic that should be unaffected taking 151 sub-optimal paths until the high cost metric is reverted to the 152 normal cost. In Figure 1, when B's link to the broadcast network 153 comes up and it is discovered by routers A, C and E, then A, B, C 154 and E can all start advertising maximum cost to the broadcast 155 network. A will have B as next-hop to PE2 and will not have a LDP 156 LSP path to PE2 resulting in VPN traffic from PE1 to PE2 to be 157 black-holed at A. The route churn at A also results in traffic 158 between PE1 and PE3 to be unnecessarily diverted to the sub- 159 optimal path PE1-A-PE3 until the maximum cost advertisement is 160 reverted to the normal cost. 162 This interpretation has the additional complexity of requiring 163 the maximum cost advertisement to be reverted by all routers 164 after LDP peering between all the routers on the broadcast 165 network is operational. This is non-trivial and needs co- 166 ordination between all the routers. 168 In another alternative interpretation of the applicability of 169 [LDP-IGP-SYNC] to broadcast networks, only the router whose link 170 to the broadcast network comes up, advertises maximum cost for 171 that link but other routers continue to advertise the normal 172 cost. In Figure 1 when B's link to the broadcast network comes 173 up, it advertises a high cost to the broadcast network. After the 174 IGP has converged but the LDP peering A-B is not yet operational, 175 A will have B as the next-hop for PE2 and will not have a LDP LSP 176 path to PE2. Since A's cost to reach B not high, A-B-PE2 becomes 177 the shortest path. VPN traffic from PE1 to PE2 will be dropped at 178 A. 180 4. Solution 182 The problem described above exists because the link-state 183 database (LSDB) of the IGP does not describe a link coming up on 184 a broadcast network with a high bi-directional cost to all other 185 routers on that broadcast network. A broadcast network is 186 advertised as a pseudo-node containing a list of routers that the 187 broadcast network is connected to and the cost of all these links 188 from the pseudo-node to each router is zero when computing SPF. 190 The solution proposed below removes the link that is coming up 191 from the LSDB unless absolutely necessary. Only the router whose 192 link is coming up plays a role in ensuring this. The other 193 routers on the broadcast network are not involved. The following 194 text describes this in more detail. 196 During the intra-area SPF algorithm execution, an additional 197 computation is made to detect an alternate path to a directly 198 connected network that does not have any IGP adjacencies. 200 If a router has a directly connected network that does not have 201 an alternate path to reach it, then the interface to that network 202 is a 'cut-edge' in the topology for that router. When a 'cut- 203 edge' goes down, the network is partitioned into two disjoint 204 sub-graphs. This property of whether or not an interface is a 205 'cut-edge' is used when an IGP adjacency comes up on that 206 interface. The method to determine whether an interface is a 207 'cut-edge' is described in Appendix A. 209 During IGP procedures when the router's first adjacency to the 210 broadcast network is coming up and the LSA is about to be updated 211 with a link to the pseudo-node of the broadcast interface, a 212 check is made whether that interface is a 'cut-edge'. If it is 213 not a 'cut-edge' then the updating of the LSA with that link to 214 the pseudo-node is postponed until LDP is operational with all 215 the LDP peers on that broadcast interface. After LDP is 216 operational, the LSA is updated with that link to the pseudo-node 217 (and the LSA is flooded). If the interface is a 'cut-edge' then 218 the updating of the LSA must not be delayed by LDP's operational 219 state. Note that the IGP and LDP adjacency bring-up procedures 220 are unchanged. The conditional check whether the interface is a 221 'cut-edge' must be done just before the adjacency is about to be 222 reflected in the LSA. 224 If the IGP is [OSPF], the Router-LSA is not updated with a 'Link 225 Type 2' (link to transit network) for that subnet, until LDP is 226 operational with all neighboring routers on that subnet. 228 Similarly, if the IGP is [ISIS], the 'Link State PDU' is updated 229 with an 'IS Reachability TLV' (or an 'Extended IS Reachability 230 TLV') to the pseudo-node after LDP is operational with all 231 neighboring routers on that subnet. 233 Note that this solution can be introduced in a gradual manner in 234 a network without any backward compatibility issues. 236 5. Scope 238 This document is agnostic to the method that detects LDP to be 239 operational with a neighbor. It does not define any new method to 240 detect that LDP is operational. At the time of publishing this 241 document [LDP-EOL] seems to be the preferred method. 243 Issues arising out of LDP not being configured on some routers or 244 on some interfaces are not specific to the method described in 245 this document and are considered outside the scope of this 246 solution. 248 6. Applicability 250 The method described in this document can be easily extended to 251 point-to-point (p2p) links. However, an implementation may 252 continue to apply the method described in [LDP-IGP-SYNC] to p2p 253 links but apply the method described in this document to 254 broadcast networks. Both methods can co-exist in a network. 256 The techniques used in this document's solution enable LDP IGP 257 synchronization in many scenarios where one end of the IGP 258 adjacency does not support any LDP IGP sync method. This is an 259 optional benefit and is for further study. Some ways to apply 260 this technique to achieve that benefit are discussed in Appendix 261 B. 263 7. Security Considerations 265 This document does not introduce any new security considerations 266 beyond those already described in [LDP-IGP-SYNC]. 268 8. IANA Considerations 270 This document has no actions for IANA. 272 9. Conclusion 274 This document complements [LDP-IGP-SYNC] by providing a solution 275 to achieve LDP IGP synchronization for broadcast networks. It can 276 also co-exist with that solution in a network that has a 277 combination of p2p links and broadcast networks. It can also be 278 introduced into a network without backward compatibility issues. 280 The solution in this document can also be used exclusively to 281 achieve LDP IGP synchronization since this solution applies to 282 both p2p links as well as broadcast networks. 284 This solution also has useful properties that can be optionally 285 used to achieve LDP IGP synchronization when only one end of the 286 IGP adjacency supports this solution but the other end supports 287 neither this solution nor the one in [LDP-IGP-SYNC]. 289 10. References 291 10.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 [LDP-IGP-SYNC] Jork, M., et al, "LDP IGP Synchronization", RFC 297 5443, March 2009. 299 10.2. Informative References 301 [LDP] Andersson, L., et al, "LDP Specification", RFC 5036, 302 October 2007. 304 [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 306 [ISIS] International Organization for Standardization, 307 "Intermediate system to intermediate system intra- 308 domain-routing routine information exchange protocol 309 for use in conjunction with the protocol for providing 310 the connectionless-mode Network Service (ISO 8473)", 311 ISO Standard 10589, 1992. 313 [LDP-EOL] Asati, R., et al, "Signaling LDP Label Advertisement 314 Completion", draft-ietf-mpls-ldp-end-of-lib-04, Work in 315 progress, August 2009. 317 11. Acknowledgments 319 The authors would like to thank Luyuan Fang, Mikael Abrahamsson, 320 Ben Niven-Jenkins, Bruno Decraene, Jeff Tantsura and Acee Lindem 321 for their review and useful comments. 323 This document was prepared using 2-Word-v2.0.template.dot. 325 Appendix A. Computation of 'cut-edge' 327 A 'cut-edge' can be computed during an intra-area SPF run or by 328 using results of the previous SPF run. If a SPF run was scheduled 329 but is pending execution, that SPF must be executed immediately 330 before any procedure checks whether an interface is a 'cut-edge'. 332 An interface is considered a 'cut-edge' if during intra-area SPF 333 (using Dijkstra's algorithm) there is no alternate path for the 334 directly connected network. Alternately, lack of connectivity to 335 the router-id of a directly connected peer via an alternate path 336 as detected by the last run of SPF can be used. The router-id can 337 be known during the adjacency bring-up process. 339 A 'cut-edge' computation should not require any extra SPF runs. 340 It should not increase the algorithmic complexity of SPF. 342 Appendix B. Sync without support at one end 344 A useful property of the solution described in this document is 345 that LDP IGP synchronization is achievable in many scenarios 346 where one end of the IGP adjacency does not support any LDP IGP 347 sync method. 349 For p2p links (or broadcast links on which the IGP operates in 350 p2p mode) the applicability is straightforward. An IGP can 351 establish a p2p adjacency on a p2p link or a broadcast link with 352 the IGP in p2p mode. When a p2p adjacency comes up, the end of 353 the adjacency that supports the solution in this document would 354 not advertise the link to the other router in its LSA unless the 355 edge is a 'cut-edge' or until LDP becomes operational. Hence 356 neither of the two routers will have IGP next-hop as the other 357 router unless the link is a 'cut-edge'. Consider Figure 1 358 modified such that the broadcast network is replaced by p2p links 359 between each of A, B, C and E. Say link A-B is coming up but only 360 A has implemented the solution in this document whereas B has 361 implemented neither the solution in this document nor the 362 solution in [LDP-IGP-SYNC]. Since A's LSA does not advertise a 363 link to B until LDP is operational, B does not have A as next- 364 hop. After LDP is operational, A advertises the link to B in its 365 LSA. Hence there is no traffic loss due to LDP LSP not being 366 present. 368 For broadcast networks the applicability is not straightforward 369 and should be considered a topic for future study. One way is for 370 the DR to stop advertising the link in the pseudo-node to the 371 router whose link is coming up until LDP is operational. 373 Authors' Addresses 375 Sriganesh Kini 376 Ericsson 377 300 Holger Way, San Jose, CA 95134 379 Email: sriganesh.kini@ericsson.com 381 Wenhu Lu 382 Ericsson 383 300 Holger Way, San Jose, CA 95134 385 Email: wenhu.lu@ericsson.com