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]
