idnits 2.17.1 draft-ietf-mpls-ldp-igp-sync-bcast-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5443, but the abstract doesn't seem to directly say this. It does mention RFC5443 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5443, updated by this document, for RFC5378 checks: 2007-09-07) -- 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 (November 24, 2010) is 4900 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Kini (Ed) 3 Internet Draft W. Lu (Ed) 4 Updates: 5443 (if approved) Ericsson 5 Intended Status: Informational November 24, 2010 6 Expires: May 2011 8 LDP IGP Synchronization for broadcast networks 9 draft-ietf-mpls-ldp-igp-sync-bcast-06.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work 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 May 28, 2011. 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 respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 RFC 5443 describes a mechanism to achieve LDP IGP Synchronization 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 metric increase 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 network, 58 this can result in loss of traffic through other established peers on 59 that network. This document describes a mechanism to address that 60 use-case without dropping traffic. The mechanism does not introduce 61 any protocol message changes. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions used in this document . . . . . . . . . . . . . . . 3 67 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 73 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 10.2. Informative References . . . . . . . . . . . . . . . . . 8 77 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 78 Appendix A. Computation of 'cut-edge' . . . . . . . . . . . . . . 9 79 Appendix B. Sync without support at one end . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 In RFC 5443 ([LDP-IGP-SYNC]), when [LDP] is not fully operational on 85 a link, the IGP advertises the link with maximum cost to avoid any 86 transit traffic on the link if possible. When LDP becomes operational 87 i.e., all the label bindings have been exchanged, the link is 88 advertised with its correct cost. This tries to ensure that all along 89 the IGP shortest path, the LDP LSP is available. The mechanisms in 90 [LDP-IGP-SYNC] have limitations when applied to a broadcast link. 91 These are described in section 3. A solution is defined in section 4. 93 2. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Problem Statement 101 On broadcast networks, a router's link-state advertisement (LSA) 102 contains a single cost to the broadcast network, rather than a 103 separate cost to each peer on the broadcast network. The operation of 104 the mechanism in [LDP-IGP-SYNC] is analyzed using the sample topology 105 of Figure 1 below where routers A, B, C and E are attached to a 106 common broadcast network. Say all links in that topology have a cost 107 of 1 except the link A-PE3 that has a cost of 10. The use-case when 108 router B's link to the broadcast network comes up is analyzed. Before 109 that link comes up, traffic between PE1 and PE2 flows along the bi- 110 directional path PE1-A-C-D-PE2 and traffic between PE1 and PE3 flows 111 along the bi-directional path PE1-A-E-PE3. 113 | +---+ +---+ 114 |----| B |-----------|PE2| 115 | +---+ +---+ 116 +---+ +---+ | | 117 |PE1|----| A |----| | 118 +---+ +---+ | | 119 | | +---+ +---+ | 120 | |----| C |----| D |----+ 121 | | +---+ +---+ 122 | | 123 | | 124 | | 125 | | +---+ 126 | |----| E |-------------+ 127 | | +---+ | 128 | | | 129 | | 130 | +---+ 131 +---------------------------|PE3| 132 +---+ 134 Figure 1 LDP IGP Sync on a broadcast network 136 In one interpretation of the applicability of [LDP-IGP-SYNC] to 137 broadcast networks, when a new router is discovered on a broadcast 138 network, that network should avoid transit traffic till LDP becomes 139 operational between all routers on that network. This can be achieved 140 by having all the attached routers advertise maximum cost to that 141 network. This should result in traffic that is being sent via that 142 broadcast network to be diverted. However, traffic might be 143 inadvertently diverted to the link that just came up. Till LDP 144 becomes operational, that traffic will be black-holed. An additional 145 problem is route churn in the entire network that results in traffic 146 that should be unaffected taking sub-optimal paths until the high 147 cost metric is reverted to the normal cost. In Figure 1, when B's 148 link to the broadcast network comes up and it is discovered by 149 routers A, C and E, then A, B, C and E can all start advertising 150 maximum cost to the broadcast network. A will have B as next-hop to 151 PE2 and will not have a LDP LSP path to PE2 resulting in VPN traffic 152 from PE1 to PE2 to be black-holed at A. The route churn at A also 153 results in traffic between PE1 and PE3 to be unnecessarily diverted 154 to the sub-optimal path PE1-A-PE3 until the maximum cost 155 advertisement is reverted to the normal cost. 157 This interpretation has the additional complexity of requiring the 158 maximum cost advertisement to be reverted by all routers after LDP 159 peering between all the routers on the broadcast network is 160 operational. This is non-trivial and needs co-ordination between all 161 the routers. 163 In another alternative interpretation of the applicability of [LDP- 164 IGP-SYNC] to broadcast networks, only the router whose link to the 165 broadcast network comes up, advertises maximum cost for that link but 166 other routers continue to advertise the normal cost. In Figure 1 when 167 B's link to the broadcast network comes up, it advertises a high cost 168 to the broadcast network. After the IGP has converged but the LDP 169 peering A-B is not yet operational, A will have B as the next-hop for 170 PE2 and will not have a LDP LSP path to PE2. Since A's cost to reach 171 B is not high, A-B-PE2 becomes the shortest path. VPN traffic from 172 PE1 to PE2 will be dropped at A. 174 4. Solution 176 The problem described above exists because the link-state database 177 (LSDB) of the IGP does not describe a link coming up on a broadcast 178 network with a high bi-directional cost to all other routers on that 179 broadcast network. A broadcast network is advertised as a pseudo-node 180 containing a list of routers that the broadcast network is connected 181 to and the cost of all these links from the pseudo-node to each 182 router is zero when computing SPF (Shortest Path First). 184 The solution proposed below removes the link that is coming up from 185 the LSDB unless absolutely necessary. Only the router whose link is 186 coming up plays a role in ensuring this. The other routers on the 187 broadcast network are not involved. The following text describes this 188 in more detail. 190 During the intra-area SPF algorithm execution, an additional 191 computation is made to detect an alternate path to a directly 192 connected network that does not have any IGP adjacencies. 194 If a router has a directly connected network that does not have an 195 alternate path to reach it, then the interface to that network is a 196 'cut-edge' in the topology for that router. When a 'cut-edge' goes 197 down, the network is partitioned into two disjoint sub-graphs. This 198 property of whether or not an interface is a 'cut-edge' is used when 199 an IGP adjacency comes up on that interface. The method to determine 200 whether an interface is a 'cut-edge' is described in Appendix A. 202 During IGP procedures when the router's first adjacency to the 203 broadcast network is coming up and the LSA is about to be updated 204 with a link to the pseudo-node of the broadcast interface, a check is 205 made whether that interface is a 'cut-edge'. If it is not a 'cut- 206 edge' then the updating of the LSA with that link to the pseudo-node 207 is postponed until LDP is operational with all the LDP peers on that 208 broadcast interface. After LDP is operational, the LSA is updated 209 with that link to the pseudo-node (and the LSA is flooded). If the 210 interface is a 'cut-edge' then the updating of the LSA MUST NOT be 211 delayed by LDP's operational state. Note that the IGP and LDP 212 adjacency bring-up procedures are unchanged. The conditional check 213 whether the interface is a 'cut-edge' must be done just before the 214 adjacency is about to be reflected in the LSA. 216 If the IGP is [OSPF], the Router-LSA is not updated with a 'Link Type 217 2' (link to transit network) for that subnet, until LDP is 218 operational with all neighboring routers on that subnet. 220 Similarly, if the IGP is [ISIS], the 'Link State PDU' is updated with 221 an 'IS Reachability TLV' (or an 'Extended IS Reachability TLV') to 222 the pseudo-node after LDP is operational with all neighboring routers 223 on that subnet. 225 Note that this solution can be introduced in a gradual manner in a 226 network without any backward compatibility issues. 228 5. Scope 230 This document is agnostic to the method that detects LDP to be 231 operational with a neighbor. It does not define any new method to 232 detect that LDP is operational. At the time of publishing this 233 document [LDP-EOL] seems to be the preferred method. 235 Issues arising out of LDP not being configured on some routers or on 236 some interfaces are not specific to the method described in this 237 document and are considered outside the scope of this solution. 239 6. Applicability 241 The method described in this document can be easily extended to 242 point-to-point (p2p) links. However, an implementation may continue 243 to apply the method described in [LDP-IGP-SYNC] to p2p links but 244 apply the method described in this document to broadcast networks. 245 Both methods can co-exist in a network. 247 The techniques used in this document's solution enable LDP IGP 248 synchronization in many scenarios where one end of the IGP adjacency 249 does not support any LDP IGP sync method. This is an optional benefit 250 and is for further study. Some ways to apply this technique to 251 achieve that benefit are discussed in Appendix B. 253 7. Security Considerations 255 This document does not introduce any new security considerations 256 beyond those already described in [LDP-IGP-SYNC]. 258 Note that in [LDP-IGP-SYNC] when a link is advertised with high 259 metric, an alternate path with a large number of hops can result in 260 the end-to-end path having more than 255 hops and thus result in 261 unreachability. This fact could be exploited if control of metrics 262 falls into the hands of an attacker. 264 This problem can even exist in a plain IP network with a link-state 265 IGP. If the directly connected path has a higher metric than an 266 alternate path with TTL greater than 255 hops then the standard 267 shortest path first algorithm will conclude that the shortest path is 268 the alternate path although the neighboring node is unreachable 269 through this path. In this case the link is advertised with its 270 normal metric yet there is unreachability in the network. Thus, this 271 document does not introduce any new issues beyond those in a standard 272 IGP-based IP network, and operators need to apply policy and security 273 to the techniques used to determine and distribute the metrics used 274 on links in their networks. 276 8. IANA Considerations 278 This document has no actions for IANA. 280 9. Conclusions 282 This document complements [LDP-IGP-SYNC] by providing a solution to 283 achieve LDP IGP synchronization for broadcast networks. It can also 284 co-exist with that solution in a network that has a combination of 285 p2p links and broadcast networks. It can also be introduced into a 286 network without backward compatibility issues. The solution in this 287 document can also be used exclusively to achieve LDP IGP 288 synchronization since this solution applies to both p2p links as well 289 as broadcast networks. 291 This solution also has useful properties that can be optionally used 292 to achieve LDP IGP synchronization when only one end of the IGP 293 adjacency supports this solution but the other end supports neither 294 this solution nor the one in [LDP-IGP-SYNC]. 296 10. References 298 10.1. Normative References 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 [LDP-IGP-SYNC] Jork, M., et al, "LDP IGP Synchronization", RFC 5443, 304 March 2009. 306 [LDP] Andersson, L., et al, "LDP Specification", RFC 5036, 307 October 2007. 309 [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 311 [ISIS] International Organization for Standardization, 312 "Intermediate system to intermediate system intra-domain- 313 routing routine information exchange protocol for use in 314 conjunction with the protocol for providing the 315 connectionless-mode Network Service (ISO 8473)", ISO 316 Standard 10589, 1992. 318 10.2. Informative References 320 [LDP-EOL] Asati, R., et al, "Signaling LDP Label Advertisement 321 Completion", RFC 5919, June 2010. 323 11. Acknowledgements 325 The authors would like to thank Luyuan Fang, Mikael Abrahamsson, Ben 326 Niven-Jenkins, Bruno Decraene, Jeff Tantsura and Acee Lindem for 327 their review and useful comments. 329 Appendix A. Computation of 'cut-edge' 331 A 'cut-edge' can be computed during an intra-area SPF run or by using 332 results of the previous SPF run. If a SPF run was scheduled but is 333 pending execution, that SPF MUST be executed immediately before any 334 procedure checks whether an interface is a 'cut-edge'. 336 An interface is considered a 'cut-edge' if during intra-area SPF 337 (using Dijkstra's algorithm - see [OSPF] sec 16) there is no 338 alternate path for the directly connected network. Alternately, lack 339 of connectivity to the router-id of a directly connected peer via an 340 alternate path as detected by the last run of SPF can be used. The 341 router-id can be known during the adjacency bring-up process. 343 A 'cut-edge' computation should not require any extra SPF runs. It 344 should not increase the algorithmic complexity of SPF. 346 Appendix B. Sync without support at one end 348 A useful property of the solution described in this document is that 349 LDP IGP synchronization is achievable in many scenarios where one end 350 of the IGP adjacency does not support any LDP IGP sync method. 352 For p2p links (or broadcast links on which the IGP operates in p2p 353 mode) the applicability is straightforward. An IGP can establish a 354 p2p adjacency on a p2p link or a broadcast link with the IGP in p2p 355 mode. When a p2p adjacency comes up, the end of the adjacency that 356 supports the solution in this document would not advertise the link 357 to the other router in its LSA unless the edge is a 'cut-edge' or 358 until LDP becomes operational. Hence neither of the two routers will 359 have IGP next-hop as the other router unless the link is a 'cut- 360 edge'. Consider Figure 1 modified such that the broadcast network is 361 replaced by p2p links between each of A, B, C and E. Say link A-B is 362 coming up but only A has implemented the solution in this document 363 whereas B has implemented neither the solution in this document nor 364 the solution in [LDP-IGP-SYNC]. Since A's LSA does not advertise a 365 link to B until LDP is operational, B does not have A as next-hop. 366 After LDP is operational, A advertises the link to B in its LSA. 367 Hence there is no traffic loss due to LDP LSP not being present. 369 For broadcast networks the applicability is not straightforward and 370 should be considered a topic for future study. One way is for the DR 371 to stop advertising the link in the pseudo-node to the router whose 372 link is coming up until LDP is operational. 374 Authors' Addresses 376 Sriganesh Kini 377 Ericsson 378 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 384 EMail: wenhu.lu@ericsson.com