MPLS Working Group W. Lu Internet Draft S. Kini Intended Status: Informational Ericsson Expires: May 14, 2010 November 10, 2009 LDP IGP Synchronization for broadcast networks draft-ietf-mpls-ldp-igp-sync-bcast-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Lu & Kini Expires May 14, 2010 [Page 1] Internet-Draft LDP IGP Synchronization November 2009 for broadcast networks Abstract [LDP-IGP-SYNC] describes a mechanism to prevent black-holing traffic (e.g. VPN) when IGP is operational on a link but LDP is not. If this mechanism is applied to broadcast links that have more than one LDP/IGP peer, the cost-out procedure can only be applied to the link as a whole but not an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol changes. Table of Contents 1. Introduction .................................................. 2 2. Conventions used in this document ............................. 4 3. Proposed Solution ............................................. 4 4. Scope of the solution ......................................... 5 5. Security Considerations ....................................... 5 6. IANA Considerations ........................................... 5 7. References .................................................... 6 7.1. Normative References ..................................... 6 7.2. Informative References ................................... 6 8. Acknowledgements .............................................. 6 1. Introduction In [LDP-IGP-SYNC], when LDP is not fully operational on a link, IGP advertises the link with maximum cost to avoid any transit traffic on the link if possible. When LDP becomes operational i.e., all the label bindings have been exchanged, the link is advertised with its correct cost. This tries to ensure that all along the IGP shortest path, the LDP LSP is available. On broadcast links, IGP advertises a common cost to the broadcast link, rather than a separate cost to each peer. The operation of the mechanism in [LDP-IGP-SYNC] is analyzed using the sample topology of Figure 1 below where routers A, B, C and E are attached to a common broadcast network. Say all links in that topology have a cost of 1 except the link A-PE3 that has a cost of 10. The use-case when router B's link to the broadcast network comes up is analyzed. Before that link comes up, traffic between PE1 and PE2 flows along the bi- directional path PE1-A-C-D-PE2 and traffic between PE1 and PE3 flows along the bi-directional path PE1-A-E-PE3. Lu & Kini Expires May 14, 2010 [Page 2] Internet-Draft LDP IGP Synchronization November 2009 for broadcast networks | | +---+ +---+ |----| B |-----------|PE2| | +---+ +---+ +---+ +---+ | | |PE1|----| A |----| | +---+ +---+ | | | | +---+ +---+ | | |----| C |----| D |----+ | | +---+ +---+ | | | | | | | | +---+ | |----| E |-------------+ | | +---+ | | | | | | | +---+ +---------------------------|PE3| +---+ Figure 1 LDP IGP sync on a broadcast network In one interpretation of the applicability of [LDP-IGP-SYNC] to broadcast networks, when a new router is discovered on a broadcast network, that network should avoid transit traffic till LDP becomes operational between all routers on that network. This can be achieved by having all the attached routers advertise maximum cost to that network. This should result in traffic that is being sent via that broadcast network to be diverted. However, traffic might be inadvertently diverted to the link that just came up. Till LDP becomes operational, that traffic will be black-holed. In Figure 1, when B's link to the broadcast network comes up and it is discovered by routers A, C and E, then A, B, C and E can all start advertising maximum cost to the broadcast network. Traffic between PE1 and PE3 will be unnecessarily diverted to the sub-optimal path PE1-A-PE3 until the maximum cost advertisement is stopped. More importantly, A will have B as nexthop to PE2 and will not have a LDP LSP path to PE2 resulting in VPN traffic from PE1 to PE2 to be black-holed at A. This interpretation has the additional complexity of ensuring that the maximum cost advertisement should be reverted after LDP peering Lu & Kini Expires May 14, 2010 [Page 3] Internet-Draft LDP IGP Synchronization November 2009 for broadcast networks between all the routers on the broadcast network is operational. This is non-trivial and needs co-ordination between all the routers. In another alternative interpretation of the applicability of [LDP- IGP-SYNC] to broadcast networks, only the router whose link to the broadcast network comes up, advertises maximum cost for that link but other routers continue to advertise the normal cost. In Figure 1 when B's link to the broadcast network comes up, it advertises a high cost to the broadcast network. After IGP has converged but the LDP peering A-B is not yet operational, A will have B as the nexthop for PE2 and will not have a LDP LSP path to PE2. VPN traffic from PE1 to PE2 will be dropped at A. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Proposed Solution The problem described above exists because the link-state database (LSDB) of the IGP does not describe a link coming up on a broadcast network with a high bi-directional cost to all other routers on that broadcast network. A broadcast network is advertised as a pseudo-node containing a list of routers that the broadcast network is connected to and the cost of all these connections from the pseudo-node to the router is zero when computing SPF. The solution proposed below removes the link that is coming up from the LSDB unless absolutely necessary. Only the router whose link is coming up plays a role in ensuring this. The other routers on the broadcast network are not involved. The following text describes it in more detail. During the SPF algorithm execution, an additional computation is made to detect an alternate path to reach a directly connected broadcast network. If an alternate path does not exist, the interface is a `cut-edge' in the topology. When a router is ready to update its link-state advertisement (LSA) with a link to the pseudo-node of a broadcast interface, it first checks if that interface is a `cut-edge'. If it is not a `cut-edge' then the updating of the LSA with that link to the pseudo-node is postponed till LDP is operational with all the neighbors on that broadcast interface. After LDP is operational, the LSA is updated Lu & Kini Expires May 14, 2010 [Page 4] Internet-Draft LDP IGP Synchronization November 2009 for broadcast networks with that link to the pseudo-node (and the LSA is flooded). Note that IGP and LDP adjacency bringup procedures are unchanged. If the IGP is [OSPF], the Router-LSA is not updated with a `Link Type 2' (link to transit network) for that subnet, until LDP is operational with all neighboring routers on that subnet. Similarly, if the IGP is [ISIS], the `Link State PDU' is updated with an `IS Reachability TLV' (or an `Extended IS Reachability TLV') to the pseudo-node after LDP is operational with all neighboring routers on that subnet. A broadcast interface that is a `cut-edge' does not require special handling. Note that this solution can be introduced in a gradual manner in a network without any backward compatibility issues. 4. Scope of the solution The method described in this document can be easily extended to point-to-point links. However, an implementation may continue to apply the method described in [LDP-IGP-SYNC] to point-to-point links but apply the method described in this document to broadcast links. Both methods can co-exist in a network. This document is agnostic to the method that detects LDP to be operational with a neighbor. It does not define any new method to detect that LDP is operational. At the time of publishing this document [LDP End-of-Lib] seems to be the preferred method. Issues arising out of LDP not being configured on some routers or on some interfaces are not specific to the method described in this document and are considered outside the scope of this solution. 5. Security Considerations This document does not introduce any new security considerations beyond those already described in [LDP-IGP-SYNC]. 6. IANA Considerations This document has no actions for IANA. Lu & Kini Expires May 14, 2010 [Page 5] Internet-Draft LDP IGP Synchronization November 2009 for broadcast networks 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [LDP-IGP-SYNC] Jork, M., et al, "LDP IGP Synchronization", RFC 5443, Mar 2009. [LDP] Andersson, L., et al, "LDP Specification", RFC 5036, October 2007. [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [ISIS] International Organization for Standardization,"Intermediate system to intermediate system intra-domain-routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO Standard 10589, 1992. [LDP End-of-Lib] Asati, R., et al, "LDP End-of-LIB", draft-ietf-mpls- end-of-lib-03.txt, Jan 2009. 8. Acknowledgements The authors would like to thank Luyuan Fang, Bruno Decraene, Jeff Tantsura and Acee Lindem for their comments. Lu & Kini Expires May 14, 2010 [Page 6] Internet-Draft LDP IGP Synchronization November 2009 for broadcast networks Authors' Addresses Wenhu Lu Ericsson 300 Holger Way San Jose, CA 95134 USA Phone: +1-408-750-5436 Email: wenhu.lu@ericsson.com Sriganesh Kini Ericsson 300 Holger Way San Jose, CA 95134 USA Phone: +1-408-750-5210 Email: sriganesh.kini@ericsson.com Lu & Kini Expires May 14, 2010 [Page 7]