[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)
Updates: 5443 (if approved)                                     Ericsson
Intended Status: Informational                          October 25, 2010
Expires: April 2011

             LDP IGP Synchronization for broadcast networks
               draft-ietf-mpls-ldp-igp-sync-bcast-05.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 28, 2011.

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 Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Kini & Lu                Expires April 28, 2011                 [Page 1]

Internet Draft    LDP IGP Sync for broadcast networks        Oct 4, 2010


Abstract

   RFC 5443 describes a mechanism to achieve LDP IGP Synchronization 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 metric increase
   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 message changes.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions used in this document . . . . . . . . . . . . . . . 3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
      10.1.  Normative References  . . . . . . . . . . . . . . . . . . 7
      10.2.  Informative References  . . . . . . . . . . . . . . . . . 7
   11.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
   Appendix A.  Computation of 'cut-edge'  . . . . . . . . . . . . . . 9
   Appendix B.  Sync without support at one end  . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11


















Kini & Lu                Expires April 28, 2011                 [Page 2]

Internet Draft    LDP IGP Sync for broadcast networks        Oct 4, 2010


1.  Introduction

   In RFC 5443 ([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. 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].

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.





















Kini & Lu                Expires April 28, 2011                 [Page 3]

Internet Draft    LDP IGP Sync for broadcast networks        Oct 4, 2010


                               |    +---+           +---+
                               |----| 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. 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



Kini & Lu                Expires April 28, 2011                 [Page 4]

Internet Draft    LDP IGP Sync for broadcast networks        Oct 4, 2010


   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 is 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 (Shortest Path First).

   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



Kini & Lu                Expires April 28, 2011                 [Page 5]

Internet Draft    LDP IGP Sync for broadcast networks        Oct 4, 2010


   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.

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




Kini & Lu                Expires April 28, 2011                 [Page 6]

Internet Draft    LDP IGP Sync for broadcast networks        Oct 4, 2010


   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.  Conclusions

   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. 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.

   [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.

10.2.  Informative References

   [LDP-EOL]  Asati, R., et al, "Signaling LDP Label Advertisement



Kini & Lu                Expires April 28, 2011                 [Page 7]

Internet Draft    LDP IGP Sync for broadcast networks        Oct 4, 2010


              Completion", RFC 5919, June 2010.

11.  Acknowledgements

   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.












































Kini & Lu                Expires April 28, 2011                 [Page 8]

Internet Draft    LDP IGP Sync for broadcast networks        Oct 4, 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 - see [OSPF] sec 16) 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 April 28, 2011                 [Page 9]

Internet Draft    LDP IGP Sync for broadcast networks        Oct 4, 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 April 28, 2011                [Page 10]

Internet Draft    LDP IGP Sync for broadcast networks        Oct 4, 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 April 28, 2011                [Page 11]


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