[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 draft-ietf-mpls-ldp-igp-sync-bcast

Network Working Group                                              W. Lu
Internet Draft                                                   S. Kini
Intended Status: Informational                                  Ericsson
Expires: April 23, 2010                                 October 20, 2009


                 LDP IGP Synchronization for broadcast networks
                       draft-lu-ldp-igp-sync-bcast-01.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 April 23, 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 April 23, 2010              [Page 1]

Internet-Draft         LDP IGP Synchronization              October 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 April 23, 2010                [Page 2]

Internet-Draft            LDP IGP Synchronization           October 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 April 23, 2010                    [Page 3]

Internet-Draft            LDP IGP Synchronization           October 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 April 23, 2010               [Page 4]

Internet-Draft              LDP IGP Synchronization         October 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 April 23, 2010                 [Page 5]

Internet-Draft             LDP IGP Synchronization          October 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 April 23, 2010              [Page 6]

Internet-Draft             LDP IGP Synchronization        October 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 April 23, 2010              [Page 7]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/