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