draft-ietf-mpls-ldp-igp-sync-bcast-00.txt   draft-ietf-mpls-ldp-igp-sync-bcast-01.txt 
MPLS Working Group W. Lu MPLS Working Group S. Kini (Ed)
Internet Draft S. Kini Internet Draft W. Lu (Ed)
Intended Status: Informational Ericsson Intended status: Standards Track Ericsson
Expires: May 14, 2010 November 10, 2009 Expires: September 2010 March 22, 2010
LDP IGP Synchronization for broadcast networks LDP IGP Synchronization for broadcast networks
draft-ietf-mpls-ldp-igp-sync-bcast-00.txt draft-ietf-mpls-ldp-igp-sync-bcast-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with
provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-
material or to cite them other than as "work in progress." Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 14, 2010. This Internet-Draft will expire on September 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. 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.
for broadcast networks Abstract
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.
[LDP-IGP-SYNC] describes a mechanism to prevent black-holing traffic Table of Contents
(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 .............................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 .................................................. 2 1. Introduction
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,
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.
In [LDP-IGP-SYNC], when LDP is not fully operational on a link, IGP The mechanisms in [LDP-IGP-SYNC] have limitations when applied to
advertises the link with maximum cost to avoid any transit traffic on a broadcast link. These are described in section 3. A solution is
the link if possible. When LDP becomes operational i.e., all the defined in section 4.
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 2. Conventions used in this document
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.
for broadcast networks 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
| +---+ +---+
|----| B |-----------|PE2|
| +---+ +---+
+---+ +---+ | |
|PE1|----| A |----| |
+---+ +---+ | |
| | +---+ +---+ |
| |----| C |----| D |----+
| | +---+ +---+
| |
| |
| |
| | +---+
| |----| E |-------------+
| | +---+ |
| | |
| |
| +---+
+---------------------------|PE3|
+---+
Figure 1 LDP IGP sync on a broadcast network 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.
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 |----| B |-----------|PE2|
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 |PE1|----| A |----| |
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, | |----| C |----| D |----+
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 | |----| E |-------------+
resulting in VPN traffic from PE1 to PE2 to be black-holed at A. | | +---+ |
| | |
| |
| +---+
+---------------------------|PE3|
+---+
This interpretation has the additional complexity of ensuring that Figure 1 LDP IGP Sync on a broadcast network
the maximum cost advertisement should be reverted after LDP peering
for broadcast networks
between all the routers on the broadcast network is operational. This In one interpretation of the applicability of [LDP-IGP-SYNC] to
is non-trivial and needs co-ordination between all the routers. 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.
In another alternative interpretation of the applicability of [LDP- This interpretation has the additional complexity of requiring
IGP-SYNC] to broadcast networks, only the router whose link to the the maximum cost advertisement to be reverted by all routers
broadcast network comes up, advertises maximum cost for that link but after LDP peering between all the routers on the broadcast
other routers continue to advertise the normal cost. In Figure 1 when network is operational. This is non-trivial and needs co-
B's link to the broadcast network comes up, it advertises a high cost ordination between all the routers.
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 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 4. Solution
"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 links
from the pseudo-node to each router is zero when computing SPF.
The problem described above exists because the link-state database The solution proposed below removes the link that is coming up
(LSDB) of the IGP does not describe a link coming up on a broadcast from the LSDB unless absolutely necessary. Only the router whose
network with a high bi-directional cost to all other routers on that link is coming up plays a role in ensuring this. The other
broadcast network. A broadcast network is advertised as a pseudo-node routers on the broadcast network are not involved. The following
containing a list of routers that the broadcast network is connected text describes this in more detail.
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 During the intra-area SPF algorithm execution, an additional
the LSDB unless absolutely necessary. Only the router whose link is computation is made to detect an alternate path to a directly
coming up plays a role in ensuring this. The other routers on the connected network that does not have any IGP adjacencies.
broadcast network are not involved. The following text describes it
in more detail.
During the SPF algorithm execution, an additional computation is made If a router has a directly connected network that does not have
to detect an alternate path to reach a directly connected broadcast an alternate path to reach it, then the interface to that network
network. If an alternate path does not exist, the interface is a is a 'cut-edge' in the topology for that router. When a 'cut-
`cut-edge' in the topology. 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.
When a router is ready to update its link-state advertisement (LSA) During IGP procedures when the router's first adjacency to the
with a link to the pseudo-node of a broadcast interface, it first broadcast network is coming up and the LSA is about to be updated
checks if that interface is a `cut-edge'. If it is not a `cut-edge' with a link to the pseudo-node of the broadcast interface, a
then the updating of the LSA with that link to the pseudo-node is check is made whether that interface is a 'cut-edge'. If it is
postponed till LDP is operational with all the neighbors on that not a 'cut-edge' then the updating of the LSA with that link to
broadcast interface. After LDP is operational, the LSA is updated the pseudo-node is postponed until LDP is operational with all
for broadcast networks 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.
with that link to the pseudo-node (and the LSA is flooded). Note that If the IGP is [OSPF], the Router-LSA is not updated with a 'Link
IGP and LDP adjacency bringup procedures are unchanged. Type 2' (link to transit network) for that subnet, until LDP is
operational with all neighboring routers on that subnet.
If the IGP is [OSPF], the Router-LSA is not updated with a `Link Type Similarly, if the IGP is [ISIS], the 'Link State PDU' is updated
2' (link to transit network) for that subnet, until LDP is with an 'IS Reachability TLV' (or an 'Extended IS Reachability
operational with all neighboring routers on that subnet. TLV') to the pseudo-node after LDP is operational with all
neighboring routers on that subnet.
Similarly, if the IGP is [ISIS], the `Link State PDU' is updated with Note that this solution can be introduced in a gradual manner in
an `IS Reachability TLV' (or an `Extended IS Reachability TLV') to a network without any backward compatibility issues.
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 5. Scope
handling.
Note that this solution can be introduced in a gradual manner in a This document is agnostic to the method that detects LDP to be
network without any backward compatibility issues. 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.
4. Scope of the solution 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.
The method described in this document can be easily extended to 6. Applicability
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 The method described in this document can be easily extended to
operational with a neighbor. It does not define any new method to point-to-point (p2p) links. However, an implementation may
detect that LDP is operational. At the time of publishing this continue to apply the method described in [LDP-IGP-SYNC] to p2p
document [LDP End-of-Lib] seems to be the preferred method. links but apply the method described in this document to
broadcast networks. Both methods can co-exist in a network.
Issues arising out of LDP not being configured on some routers or on The techniques used in this document's solution enable LDP IGP
some interfaces are not specific to the method described in this synchronization in many scenarios where one end of the IGP
document and are considered outside the scope of this solution. 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.
5. Security Considerations 7. Security Considerations
This document does not introduce any new security considerations This document does not introduce any new security considerations
beyond those already described in [LDP-IGP-SYNC]. beyond those already described in [LDP-IGP-SYNC].
6. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
for broadcast networks 9. Conclusion
7. References 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.
7.1. Normative References 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate This solution also has useful properties that can be optionally
Requirement Levels", BCP 14, RFC 2119, March 1997. 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].
7.2. Informative References 10. References
[LDP-IGP-SYNC] Jork, M., et al, "LDP IGP Synchronization", RFC 5443, 10.1. Normative References
Mar 2009.
[LDP] Andersson, L., et al, "LDP Specification", RFC 5036, October [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2007. Requirement Levels", BCP 14, RFC 2119, March 1997.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [LDP-IGP-SYNC] Jork, M., et al, "LDP IGP Synchronization", RFC
5443, March 2009.
[ISIS] International Organization for Standardization,"Intermediate 10.2. Informative References
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- [LDP] Andersson, L., et al, "LDP Specification", RFC 5036,
end-of-lib-03.txt, Jan 2009. October 2007.
8. Acknowledgements [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
The authors would like to thank Luyuan Fang, Bruno Decraene, Jeff [ISIS] International Organization for Standardization,
Tantsura and Acee Lindem for their comments. "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.
for broadcast networks [LDP-EOL] Asati, R., et al, "Signaling LDP Label Advertisement
Completion", draft-ietf-mpls-ldp-end-of-lib-04, Work in
progress, August 2009.
Authors' Addresses 11. Acknowledgments
Wenhu Lu The authors would like to thank Luyuan Fang, Mikael Abrahamsson,
Ericsson Ben Niven-Jenkins, Bruno Decraene, Jeff Tantsura and Acee Lindem
300 Holger Way for their review and useful comments.
San Jose, CA 95134
USA
Phone: +1-408-750-5436 This document was prepared using 2-Word-v2.0.template.dot.
Email: wenhu.lu@ericsson.com
Sriganesh Kini Appendix A. Computation of 'cut-edge'
Ericsson
300 Holger Way
San Jose, CA 95134
USA
Phone: +1-408-750-5210 A 'cut-edge' can be computed during an intra-area SPF run or by
Email: sriganesh.kini@ericsson.com 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.
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.
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
 End of changes. 65 change blocks. 
216 lines changed or deleted 261 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/