idnits 2.17.1 draft-lu-ldp-igp-sync-bcast-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 (October 20, 2009) is 5299 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'LDP' is defined on line 244, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Lu 3 Internet Draft S. Kini 4 Intended Status: Informational Ericsson 5 Expires: April 23, 2010 October 20, 2009 7 LDP IGP Synchronization for broadcast networks 8 draft-lu-ldp-igp-sync-bcast-01.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 April 23, 2010. 33 Copyright Notice 35 Copyright (c) 2009 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 in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 for broadcast networks 46 Abstract 48 [LDP-IGP-SYNC] describes a mechanism to prevent black-holing traffic 49 (e.g. VPN) when IGP is operational on a link but LDP is not. If this 50 mechanism is applied to broadcast links that have more than one 51 LDP/IGP peer, the cost-out procedure can only be applied to the link 52 as a whole but not an individual peer. When a new LDP peer comes up 53 on a broadcast network, this can result in loss of traffic through 54 other established peers on that network. This document describes a 55 mechanism to address that use-case without dropping traffic. The 56 mechanism does not introduce any protocol changes. 58 Table of Contents 60 1. Introduction .................................................. 2 61 2. Conventions used in this document ............................. 4 62 3. Proposed Solution ............................................. 4 63 4. Scope of the solution ......................................... 5 64 5. Security Considerations ....................................... 5 65 6. IANA Considerations ........................................... 5 66 7. References .................................................... 6 67 7.1. Normative References ..................................... 6 68 7.2. Informative References ................................... 6 69 8. Acknowledgements .............................................. 6 71 1. Introduction 73 In [LDP-IGP-SYNC], when LDP is not fully operational on a link, IGP 74 advertises the link with maximum cost to avoid any transit traffic on 75 the link if possible. When LDP becomes operational i.e., all the 76 label bindings have been exchanged, the link is advertised with its 77 correct cost. This tries to ensure that all along the IGP shortest 78 path, the LDP LSP is available. 80 On broadcast links, IGP advertises a common cost to the broadcast 81 link, rather than a separate cost to each peer. The operation of the 82 mechanism in [LDP-IGP-SYNC] is analyzed using the sample topology of 83 Figure 1 below where routers A, B, C and E are attached to a common 84 broadcast network. Say all links in that topology have a cost of 1 85 except the link A-PE3 that has a cost of 10. The use-case when router 86 B's link to the broadcast network comes up is analyzed. Before that 87 link comes up, traffic between PE1 and PE2 flows along the bi- 88 directional path PE1-A-C-D-PE2 and traffic between PE1 and PE3 flows 89 along the bi-directional path PE1-A-E-PE3. 91 for broadcast networks 93 | 94 | +---+ +---+ 95 |----| B |-----------|PE2| 96 | +---+ +---+ 97 +---+ +---+ | | 98 |PE1|----| A |----| | 99 +---+ +---+ | | 100 | | +---+ +---+ | 101 | |----| C |----| D |----+ 102 | | +---+ +---+ 103 | | 104 | | 105 | | 106 | | +---+ 107 | |----| E |-------------+ 108 | | +---+ | 109 | | | 110 | | 111 | +---+ 112 +---------------------------|PE3| 113 +---+ 115 Figure 1 LDP IGP sync on a broadcast network 117 In one interpretation of the applicability of [LDP-IGP-SYNC] to 118 broadcast networks, when a new router is discovered on a broadcast 119 network, that network should avoid transit traffic till LDP becomes 120 operational between all routers on that network. This can be achieved 121 by having all the attached routers advertise maximum cost to that 122 network. This should result in traffic that is being sent via that 123 broadcast network to be diverted. However, traffic might be 124 inadvertently diverted to the link that just came up. Till LDP 125 becomes operational, that traffic will be black-holed. In Figure 1, 126 when B's link to the broadcast network comes up and it is discovered 127 by routers A, C and E, then A, B, C and E can all start advertising 128 maximum cost to the broadcast network. Traffic between PE1 and PE3 129 will be unnecessarily diverted to the sub-optimal path PE1-A-PE3 130 until the maximum cost advertisement is stopped. More importantly, A 131 will have B as nexthop to PE2 and will not have a LDP LSP path to PE2 132 resulting in VPN traffic from PE1 to PE2 to be black-holed at A. 134 This interpretation has the additional complexity of ensuring that 135 the maximum cost advertisement should be reverted after LDP peering 136 for broadcast networks 138 between all the routers on the broadcast network is operational. This 139 is non-trivial and needs co-ordination between all the routers. 141 In another alternative interpretation of the applicability of [LDP- 142 IGP-SYNC] to broadcast networks, only the router whose link to the 143 broadcast network comes up, advertises maximum cost for that link but 144 other routers continue to advertise the normal cost. In Figure 1 when 145 B's link to the broadcast network comes up, it advertises a high cost 146 to the broadcast network. After IGP has converged but the LDP peering 147 A-B is not yet operational, A will have B as the nexthop for PE2 and 148 will not have a LDP LSP path to PE2. VPN traffic from PE1 to PE2 will 149 be dropped at A. 151 2. Conventions used in this document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 3. Proposed Solution 159 The problem described above exists because the link-state database 160 (LSDB) of the IGP does not describe a link coming up on a broadcast 161 network with a high bi-directional cost to all other routers on that 162 broadcast network. A broadcast network is advertised as a pseudo-node 163 containing a list of routers that the broadcast network is connected 164 to and the cost of all these connections from the pseudo-node to the 165 router is zero when computing SPF. 167 The solution proposed below removes the link that is coming up from 168 the LSDB unless absolutely necessary. Only the router whose link is 169 coming up plays a role in ensuring this. The other routers on the 170 broadcast network are not involved. The following text describes it 171 in more detail. 173 During the SPF algorithm execution, an additional computation is made 174 to detect an alternate path to reach a directly connected broadcast 175 network. If an alternate path does not exist, the interface is a 176 `cut-edge' in the topology. 178 When a router is ready to update its link-state advertisement (LSA) 179 with a link to the pseudo-node of a broadcast interface, it first 180 checks if that interface is a `cut-edge'. If it is not a `cut-edge' 181 then the updating of the LSA with that link to the pseudo-node is 182 postponed till LDP is operational with all the neighbors on that 183 broadcast interface. After LDP is operational, the LSA is updated 184 for broadcast networks 186 with that link to the pseudo-node (and the LSA is flooded). Note that 187 IGP and LDP adjacency bringup procedures are unchanged. 189 If the IGP is [OSPF], the Router-LSA is not updated with a `Link Type 190 2' (link to transit network) for that subnet, until LDP is 191 operational with all neighboring routers on that subnet. 193 Similarly, if the IGP is [ISIS], the `Link State PDU' is updated with 194 an `IS Reachability TLV' (or an `Extended IS Reachability TLV') to 195 the pseudo-node after LDP is operational with all neighboring routers 196 on that subnet. 198 A broadcast interface that is a `cut-edge' does not require special 199 handling. 201 Note that this solution can be introduced in a gradual manner in a 202 network without any backward compatibility issues. 204 4. Scope of the solution 206 The method described in this document can be easily extended to 207 point-to-point links. However, an implementation may continue to 208 apply the method described in [LDP-IGP-SYNC] to point-to-point links 209 but apply the method described in this document to broadcast links. 210 Both methods can co-exist in a network. 212 This document is agnostic to the method that detects LDP to be 213 operational with a neighbor. It does not define any new method to 214 detect that LDP is operational. At the time of publishing this 215 document [LDP End-of-Lib] seems to be the preferred method. 217 Issues arising out of LDP not being configured on some routers or on 218 some interfaces are not specific to the method described in this 219 document and are considered outside the scope of this solution. 221 5. Security Considerations 223 This document does not introduce any new security considerations 224 beyond those already described in [LDP-IGP-SYNC]. 226 6. IANA Considerations 228 This document has no actions for IANA. 230 for broadcast networks 232 7. References 234 7.1. Normative References 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 7.2. Informative References 241 [LDP-IGP-SYNC] Jork, M., et al, "LDP IGP Synchronization", RFC 5443, 242 Mar 2009. 244 [LDP] Andersson, L., et al, "LDP Specification", RFC 5036, October 245 2007. 247 [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 249 [ISIS] International Organization for Standardization,"Intermediate 250 system to intermediate system intra-domain-routing routine 251 information exchange protocol for use in conjunction with the 252 protocol for providing the connectionless-mode Network Service 253 (ISO 8473)", ISO Standard 10589, 1992. 255 [LDP End-of-Lib] Asati, R., et al, "LDP End-of-LIB", draft-ietf-mpls- 256 end-of-lib-03.txt, Jan 2009. 258 8. Acknowledgements 260 The authors would like to thank Luyuan Fang, Bruno Decraene, Jeff 261 Tantsura and Acee Lindem for their comments. 263 for broadcast networks 265 Authors' Addresses 267 Wenhu Lu 268 Ericsson 269 300 Holger Way 270 San Jose, CA 95134 271 USA 273 Phone: +1-408-750-5436 274 Email: wenhu.lu@ericsson.com 276 Sriganesh Kini 277 Ericsson 278 300 Holger Way 279 San Jose, CA 95134 280 USA 282 Phone: +1-408-750-5210 283 Email: sriganesh.kini@ericsson.com