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

Versions: (draft-lu-ldp-igp-sync-bcast) 00 01 02 03 04 05 06 RFC 6138

 MPLS Working Group                                      S. Kini (Ed)
 Internet Draft                                            W. Lu (Ed)
 Intended status: Standards Track                            Ericsson
 Expires: September 2010                               March 22, 2010
 
 
 
 
              LDP IGP Synchronization for broadcast networks
                 draft-ietf-mpls-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 September 22, 2010.
 
 Copyright Notice
 
    Copyright (c) 2010 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
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document. Please review these documents
    carefully, as they describe your rights and restrictions with
    respect to this document. Code Components extracted from this
    document must include Simplified BSD License text as described in
 
 
 
 
 
 Kini & Lu             Expires September 22, 2010            [Page 1]
 

 Internet-Draft   LDP IGP Sync for broadcast networks      March 2010
 
 
 
    Section 4.e of the Trust Legal Provisions and are provided
    without warranty as described in the Simplified BSD License.
 
 Abstract
 
    LDP IGP Synchronization ([LDP-IGP-SYNC]) describes a mechanism to
    prevent black-holing traffic (e.g. VPN) when an interior gateway
    protocol (IGP) is operational on a link but Label Distribution
    Protocol (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 .............................3
    3. Problem Statement .............................................4
    4. Solution ......................................................5
    5. Scope .........................................................7
    6. Applicability .................................................7
    7. Security Considerations .......................................7
    8. IANA Considerations ...........................................7
    9. Conclusion ....................................................7
    10. References ...................................................8
       10.1. Normative References ....................................8
       10.2. Informative References ..................................8
    11. Acknowledgments ..............................................8
    Appendix A. Computation of 'cut-edge' ............................9
    Appendix B. Sync without support at one end .....................10
 
 1. Introduction
 
    In [LDP-IGP-SYNC], when LDP is not fully operational on a link,
    the 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.
 
 
 
 
 
 
 Kini & Lu             Expires September 22, 2010            [Page 2]
 

 Internet-Draft   LDP IGP Sync for broadcast networks      March 2010
 
 
 
    The mechanisms in [LDP-IGP-SYNC] have limitations when applied to
    a broadcast link. These are described in section 3. A solution is
    defined in section 4.
 
 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].
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Kini & Lu             Expires September 22, 2010            [Page 3]
 

 Internet-Draft   LDP IGP Sync for broadcast networks      March 2010
 
 
 
 3. Problem Statement
 
    On broadcast networks, a router's link-state advertisement (LSA)
    contains a single cost to the broadcast network, rather than a
    separate cost to each peer on the broadcast network. 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.
 
 
 
                           |
                           |    +---+           +---+
                           |----| 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
 
 
 
 
 Kini & Lu             Expires September 22, 2010            [Page 4]
 

 Internet-Draft   LDP IGP Sync for broadcast networks      March 2010
 
 
 
    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. An additional problem is route churn in the entire
    network that results in traffic that should be unaffected taking
    sub-optimal paths until the high cost metric is reverted to the
    normal cost. 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. A will have B as next-hop 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. The route churn at A also results in traffic
    between PE1 and PE3 to be unnecessarily diverted to the sub-
    optimal path PE1-A-PE3 until the maximum cost advertisement is
    reverted to the normal cost.
 
    This interpretation has the additional complexity of requiring
    the maximum cost advertisement to be reverted by all routers
    after LDP peering 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 the
    IGP has converged but the LDP peering A-B is not yet operational,
    A will have B as the next-hop for PE2 and will not have a LDP LSP
    path to PE2. Since A's cost to reach B not high, A-B-PE2 becomes
    the shortest path. VPN traffic from PE1 to PE2 will be dropped at
    A.
 
 4. 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 links
    from the pseudo-node to each router is zero when computing SPF.
 
 
 
 
 
 
 Kini & Lu             Expires September 22, 2010            [Page 5]
 

 Internet-Draft   LDP IGP Sync for broadcast networks      March 2010
 
 
 
    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 this in more detail.
 
    During the intra-area SPF algorithm execution, an additional
    computation is made to detect an alternate path to a directly
    connected network that does not have any IGP adjacencies.
 
    If a router has a directly connected network that does not have
    an alternate path to reach it, then the interface to that network
    is a 'cut-edge' in the topology for that router. When a 'cut-
    edge' goes down, the network is partitioned into two disjoint
    sub-graphs. This property of whether or not an interface is a
    'cut-edge' is used when an IGP adjacency comes up on that
    interface. The method to determine whether an interface is a
    'cut-edge' is described in Appendix A.
 
    During IGP procedures when the router's first adjacency to the
    broadcast network is coming up and the LSA is about to be updated
    with a link to the pseudo-node of the broadcast interface, a
    check is made whether 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 until LDP is operational with all
    the LDP peers on that broadcast interface. After LDP is
    operational, the LSA is updated with that link to the pseudo-node
    (and the LSA is flooded). If the interface is a 'cut-edge' then
    the updating of the LSA must not be delayed by LDP's operational
    state. Note that the IGP and LDP adjacency bring-up procedures
    are unchanged. The conditional check whether the interface is a
    'cut-edge' must be done just before the adjacency is about to be
    reflected in the LSA.
 
    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.
 
    Note that this solution can be introduced in a gradual manner in
    a network without any backward compatibility issues.
 
 
 
 
 
 Kini & Lu             Expires September 22, 2010            [Page 6]
 

 Internet-Draft   LDP IGP Sync for broadcast networks      March 2010
 
 
 
 5. Scope
 
    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-EOL] 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.
 
 6. Applicability
 
    The method described in this document can be easily extended to
    point-to-point (p2p) links. However, an implementation may
    continue to apply the method described in [LDP-IGP-SYNC] to p2p
    links but apply the method described in this document to
    broadcast networks. Both methods can co-exist in a network.
 
    The techniques used in this document's solution enable LDP IGP
    synchronization in many scenarios where one end of the IGP
    adjacency does not support any LDP IGP sync method. This is an
    optional benefit and is for further study. Some ways to apply
    this technique to achieve that benefit are discussed in Appendix
    B.
 
 7. Security Considerations
 
    This document does not introduce any new security considerations
    beyond those already described in [LDP-IGP-SYNC].
 
 8. IANA Considerations
 
    This document has no actions for IANA.
 
 9. Conclusion
 
    This document complements [LDP-IGP-SYNC] by providing a solution
    to achieve LDP IGP synchronization for broadcast networks. It can
    also co-exist with that solution in a network that has a
    combination of p2p links and broadcast networks. It can also be
    introduced into a network without backward compatibility issues.
 
 
 
 
 
 
 
 
 Kini & Lu             Expires September 22, 2010            [Page 7]
 

 Internet-Draft   LDP IGP Sync for broadcast networks      March 2010
 
 
 
    The solution in this document can also be used exclusively to
    achieve LDP IGP synchronization since this solution applies to
    both p2p links as well as broadcast networks.
 
    This solution also has useful properties that can be optionally
    used to achieve LDP IGP synchronization when only one end of the
    IGP adjacency supports this solution but the other end supports
    neither this solution nor the one in [LDP-IGP-SYNC].
 
 10. References
 
 10.1. Normative References
 
    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 
    [LDP-IGP-SYNC] Jork, M., et al, "LDP IGP Synchronization", RFC
              5443, March 2009.
 
 10.2. Informative References
 
    [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-EOL] Asati, R., et al, "Signaling LDP Label Advertisement
              Completion", draft-ietf-mpls-ldp-end-of-lib-04, Work in
              progress, August 2009.
 
 11. Acknowledgments
 
    The authors would like to thank Luyuan Fang, Mikael Abrahamsson,
    Ben Niven-Jenkins, Bruno Decraene, Jeff Tantsura and Acee Lindem
    for their review and useful comments.
 
    This document was prepared using 2-Word-v2.0.template.dot.
 
 
 
 
 
 
 Kini & Lu             Expires September 22, 2010            [Page 8]
 

 Internet-Draft    LDP IGP Sync for broadcast networks      March 2010
 
 
 
 Appendix A. Computation of 'cut-edge'
 
    A 'cut-edge' can be computed during an intra-area SPF run or by
    using results of the previous SPF run. If a SPF run was scheduled
    but is pending execution, that SPF must be executed immediately
    before any procedure checks whether an interface is a 'cut-edge'.
 
    An interface is considered a 'cut-edge' if during intra-area SPF
    (using Dijkstra's algorithm) there is no alternate path for the
    directly connected network. Alternately, lack of connectivity to
    the router-id of a directly connected peer via an alternate path
    as detected by the last run of SPF can be used. The router-id can
    be known during the adjacency bring-up process.
 
    A 'cut-edge' computation should not require any extra SPF runs.
    It should not increase the algorithmic complexity of SPF.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Kini & Lu              Expires September 22, 2010            [Page 9]
 

 Internet-Draft    LDP IGP Sync for broadcast networks      March 2010
 
 
 
 Appendix B. Sync without support at one end
 
    A useful property of the solution described in this document is
    that LDP IGP synchronization is achievable in many scenarios
    where one end of the IGP adjacency does not support any LDP IGP
    sync method.
 
    For p2p links (or broadcast links on which the IGP operates in
    p2p mode) the applicability is straightforward. An IGP can
    establish a p2p adjacency on a p2p link or a broadcast link with
    the IGP in p2p mode. When a p2p adjacency comes up, the end of
    the adjacency that supports the solution in this document would
    not advertise the link to the other router in its LSA unless the
    edge is a 'cut-edge' or until LDP becomes operational. Hence
    neither of the two routers will have IGP next-hop as the other
    router unless the link is a 'cut-edge'. Consider Figure 1
    modified such that the broadcast network is replaced by p2p links
    between each of A, B, C and E. Say link A-B is coming up but only
    A has implemented the solution in this document whereas B has
    implemented neither the solution in this document nor the
    solution in [LDP-IGP-SYNC]. Since A's LSA does not advertise a
    link to B until LDP is operational, B does not have A as next-
    hop. After LDP is operational, A advertises the link to B in its
    LSA. Hence there is no traffic loss due to LDP LSP not being
    present.
 
    For broadcast networks the applicability is not straightforward
    and should be considered a topic for future study. One way is for
    the DR to stop advertising the link in the pseudo-node to the
    router whose link is coming up until LDP is operational.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Kini & Lu              Expires September 22, 2010           [Page 10]
 

 Internet-Draft   LDP IGP Sync for broadcast networks      March 2010
 
 
 
 Authors' Addresses
 
    Sriganesh Kini
    Ericsson
    300 Holger Way, San Jose, CA 95134
 
    Email: sriganesh.kini@ericsson.com
 
 
 
    Wenhu Lu
    Ericsson
    300 Holger Way, San Jose, CA 95134
 
    Email: wenhu.lu@ericsson.com
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Kini & Lu             Expires September 22, 2010           [Page 11]
 

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