draft-ietf-mpls-ldp-igp-sync-bcast-06.txt   rfc6138.txt 
MPLS Working Group S. Kini (Ed) Internet Engineering Task Force (IETF) S. Kini, Ed.
Internet Draft W. Lu (Ed) Request for Comments: 6138 W. Lu, Ed.
Updates: 5443 (if approved) Ericsson Updates: 5443 Ericsson
Intended Status: Informational November 24, 2010 Category: Informational February 2011
Expires: May 2011 ISSN: 2070-1721
LDP IGP Synchronization for broadcast networks
draft-ietf-mpls-ldp-igp-sync-bcast-06.txt
Status of this Memo LDP IGP Synchronization for Broadcast Networks
This Internet-Draft is submitted to IETF in full conformance with the Abstract
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering RFC 5443 describes a mechanism to achieve LDP IGP synchronization to
Task Force (IETF), its areas, and its working groups. Note that prevent black-holing traffic (e.g., VPN) when an Interior Gateway
other groups may also distribute working documents as Internet- Protocol (IGP) is operational on a link but Label Distribution
Drafts. Protocol (LDP) is not. If this mechanism is applied to broadcast
links that have more than one LDP peer, the metric increase procedure
can only be applied to the link as a whole but not to 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.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on May 28, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6138.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Conventions used in this document . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document ...............................2
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement ...............................................2
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Solution ........................................................4
5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Scope ...........................................................5
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Applicability ...................................................5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations .........................................6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Conclusions .....................................................6
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References ......................................................7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References .......................................7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References .....................................7
10.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments ....................................................7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Computation of "Cut-Edge" ..............................8
Appendix A. Computation of 'cut-edge' . . . . . . . . . . . . . . 9 Appendix B. Sync without Support at One End ........................8
Appendix B. Sync without support at one end . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In RFC 5443 ([LDP-IGP-SYNC]), when [LDP] is not fully operational on In RFC 5443 [LDP-IGP-SYNC], when [LDP] is not fully operational on a
a link, the IGP advertises the link with maximum cost to avoid any link, the IGP advertises the link with maximum cost to avoid any
transit traffic on the link if possible. When LDP becomes operational transit traffic on the link if possible. When LDP becomes
i.e., all the label bindings have been exchanged, the link is operational, i.e., all the label bindings have been exchanged, the
advertised with its correct cost. This tries to ensure that all along link is advertised with its correct cost. This tries to ensure that
the IGP shortest path, the LDP LSP is available. The mechanisms in the LDP Label Switch Path (LSP) is available all along the IGP
[LDP-IGP-SYNC] have limitations when applied to a broadcast link. shortest path. The mechanisms in [LDP-IGP-SYNC] have limitations
These are described in section 3. A solution is defined in section 4. 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 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Problem Statement 3. Problem Statement
On broadcast networks, a router's link-state advertisement (LSA) On broadcast networks, a router's Link State Advertisement (LSA)
contains a single cost to the broadcast network, rather than a contains a single cost to the broadcast network rather than a
separate cost to each peer on the broadcast network. The operation of separate cost to each peer on the broadcast network. The operation
the mechanism in [LDP-IGP-SYNC] is analyzed using the sample topology of the mechanism in [LDP-IGP-SYNC] is analyzed using the sample
of Figure 1 below where routers A, B, C and E are attached to a topology in Figure 1, where routers A, B, C, and E are attached to a
common broadcast network. Say all links in that topology have a cost 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 of 1 except the link A-PE3, which has a cost of 10. The use-case
router B's link to the broadcast network comes up is analyzed. Before when router B's link to the broadcast network comes up is analyzed.
that link comes up, traffic between PE1 and PE2 flows along the bi- Before that link comes up, traffic between PE1 and PE2 flows along
directional path PE1-A-C-D-PE2 and traffic between PE1 and PE3 flows the bi-directional path PE1-A-C-D-PE2, and traffic between PE1 and
along the bi-directional path PE1-A-E-PE3. PE3 flows along the bi-directional path PE1-A-E-PE3.
| +---+ +---+ | +---+ +---+
|----| B |-----------|PE2| |----| B |-----------|PE2|
| +---+ +---+ | +---+ +---+
+---+ +---+ | | +---+ +---+ | |
|PE1|----| A |----| | |PE1|----| A |----| |
+---+ +---+ | | +---+ +---+ | |
| | +---+ +---+ | | | +---+ +---+ |
| |----| C |----| D |----+ | |----| C |----| D |----+
| | +---+ +---+ | | +---+ +---+
skipping to change at page 4, line 26 skipping to change at page 3, line 32
| | | |
| | +---+ | | +---+
| |----| E |-------------+ | |----| E |-------------+
| | +---+ | | | +---+ |
| | | | | |
| | | |
| +---+ | +---+
+---------------------------|PE3| +---------------------------|PE3|
+---+ +---+
Figure 1 LDP IGP Sync on a broadcast network Figure 1: LDP IGP Sync on a Broadcast Network
In one interpretation of the applicability of [LDP-IGP-SYNC] to In one interpretation of the applicability of [LDP-IGP-SYNC] to
broadcast networks, when a new router is discovered on a broadcast broadcast networks, when a new router is discovered on a broadcast
network, that network should avoid transit traffic till LDP becomes network, that network should avoid transit traffic until LDP becomes
operational between all routers on that network. This can be achieved operational between all routers on that network. This can be
by having all the attached routers advertise maximum cost to that achieved by having all the attached routers advertise maximum cost to
network. This should result in traffic that is being sent via that that network. This should result in traffic that is being sent via
broadcast network to be diverted. However, traffic might be that broadcast network to be diverted. However, traffic might be
inadvertently diverted to the link that just came up. Till LDP inadvertently diverted to the link that just came up. Until LDP
becomes operational, that traffic will be black-holed. An additional becomes operational, that traffic will be black-holed. An additional
problem is route churn in the entire network that results in traffic problem is route churn in the entire network that results in traffic
that should be unaffected taking sub-optimal paths until the high 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 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 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 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 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 PE2 and will not have a LDP LSP to PE2, resulting in VPN traffic from
from PE1 to PE2 to be black-holed at A. The route churn at A also PE1 to PE2 to be black-holed at A. The route churn at A also results
results in traffic between PE1 and PE3 to be unnecessarily diverted in traffic between PE1 and PE3 to be unnecessarily diverted to the
to the sub-optimal path PE1-A-PE3 until the maximum cost sub-optimal path PE1-A-PE3 until the maximum-cost advertisement is
advertisement is reverted to the normal cost. reverted to the normal cost.
This interpretation has the additional complexity of requiring the This interpretation has the additional complexity of requiring the
maximum cost advertisement to be reverted by all routers after LDP maximum-cost advertisement to be reverted by all routers after LDP
peering between all the routers on the broadcast network is peering between all the routers on the broadcast network is
operational. This is non-trivial and needs co-ordination between all operational. This is non-trivial and needs coordination between all
the routers. the routers.
In another alternative interpretation of the applicability of [LDP- In another alternative interpretation of the applicability of
IGP-SYNC] to broadcast networks, only the router whose link to the [LDP-IGP-SYNC] to broadcast networks, only the router whose link to
broadcast network comes up, advertises maximum cost for that link but the broadcast network comes up advertises maximum cost for that link,
other routers continue to advertise the normal cost. In Figure 1 when but other routers continue to advertise the normal cost. In Figure
B's link to the broadcast network comes up, it advertises a high cost 1, when B's link to the broadcast network comes up, it advertises a
to the broadcast network. After the IGP has converged but the LDP high cost to the broadcast network. After the IGP has converged but
peering A-B is not yet operational, A will have B as the next-hop for the LDP peering A-B is not yet operational, A will have B as the
PE2 and will not have a LDP LSP path to PE2. Since A's cost to reach next-hop for PE2 and will not have a LDP LSP to PE2. Since A's cost
B is not high, A-B-PE2 becomes the shortest path. VPN traffic from to reach B is not high, A-B-PE2 becomes the shortest path. VPN
PE1 to PE2 will be dropped at A. traffic from PE1 to PE2 will be dropped at A.
4. Solution 4. Solution
The problem described above exists because the link-state database The problem described above exists because the Link State Database
(LSDB) of the IGP does not describe a link coming up on a broadcast (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 network with a high bi-directional cost to all other routers on that
broadcast network. A broadcast network is advertised as a pseudo-node broadcast network. A broadcast network is advertised as a pseudonode
containing a list of routers that the broadcast network is connected containing a list of routers to which the broadcast network is
to and the cost of all these links from the pseudo-node to each connected, and the cost of all these links from the pseudonode to
router is zero when computing SPF (Shortest Path First). each router is zero when computing SPF (Shortest Path First).
The solution proposed below removes the link that is coming up from The solution proposed below removes the link that is coming up from
the LSDB unless absolutely necessary. Only the router whose link is the LSDB unless absolutely necessary. Only the router whose link is
coming up plays a role in ensuring this. The other routers on the coming up plays a role in ensuring this. The other routers on the
broadcast network are not involved. The following text describes this broadcast network are not involved. The following text describes
in more detail. this in more detail.
During the intra-area SPF algorithm execution, an additional During the intra-area SPF algorithm execution, an additional
computation is made to detect an alternate path to a directly computation is made to detect an alternate path to a directly
connected network that does not have any IGP adjacencies. connected network that does not have any IGP adjacencies.
If a router has a directly connected network that does not have an 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 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 "cut-edge" in the topology for that router. When a "cut-edge" goes
down, the network is partitioned into two disjoint sub-graphs. This 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 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 an IGP adjacency comes up on that interface. The method to determine
whether an interface is a 'cut-edge' is described in Appendix A. whether an interface is a "cut-edge" is described in Appendix A.
During IGP procedures when the router's first adjacency to the During IGP procedures, when the router's first adjacency to the
broadcast network is coming up and the LSA is about to be updated 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 with a link to the pseudonode of the broadcast interface, a check is
made whether that interface is a 'cut-edge'. If it is not a 'cut- made whether that interface is a "cut-edge". If it is not a
edge' then the updating of the LSA with that link to the pseudo-node "cut-edge", then the updating of the LSA with that link to the
is postponed until LDP is operational with all the LDP peers on that pseudonode is postponed until LDP is operational with all the LDP
broadcast interface. After LDP is operational, the LSA is updated peers on that broadcast interface. After LDP is operational, the LSA
with that link to the pseudo-node (and the LSA is flooded). If the is updated with that link to the pseudonode (and the LSA is flooded).
interface is a 'cut-edge' then the updating of the LSA MUST NOT be If the interface is a "cut-edge", then the updating of the LSA MUST
delayed by LDP's operational state. Note that the IGP and LDP NOT be delayed by LDP's operational state. Note that the IGP and LDP
adjacency bring-up procedures are unchanged. The conditional check adjacency bring-up procedures are unchanged. The conditional check
whether the interface is a 'cut-edge' must be done just before the of whether the interface is a "cut-edge" must be done just before the
adjacency is about to be reflected in the LSA. adjacency is about to be reflected in the LSA.
If the IGP is [OSPF], the Router-LSA is not updated with a 'Link Type 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 2" (link to transit network) for that subnet until LDP is operational
operational with all neighboring routers on that subnet. with all neighboring routers on that subnet.
Similarly, if the IGP is [ISIS], the 'Link State PDU' is updated with Similarly, if the IGP is [IS-IS], the "Link State PDU" is updated
an 'IS Reachability TLV' (or an 'Extended IS Reachability TLV') to with an "IS Reachability TLV" (or an "Extended IS Reachability TLV")
the pseudo-node after LDP is operational with all neighboring routers to the pseudonode after LDP is operational with all neighboring
on that subnet. routers on that subnet.
Note that this solution can be introduced in a gradual manner in a Note that this solution can be introduced in a gradual manner in a
network without any backward compatibility issues. network without any backward compatibility issues.
5. Scope 5. Scope
This document is agnostic to the method that detects LDP to be This document is agnostic to the method that detects LDP to be
operational with a neighbor. It does not define any new method to operational with a neighbor. It does not define any new method to
detect that LDP is operational. At the time of publishing this detect that LDP is operational. At the time of publishing this
document [LDP-EOL] seems to be the preferred method. document, LDP End-of-LIB [LDP-EOL] seems to be the preferred method.
Issues arising out of LDP not being configured on some routers or on Issues arising out of LDP not being configured on some routers or on
some interfaces are not specific to the method described in this some interfaces are not specific to the method described in this
document and are considered outside the scope of this solution. document and are considered outside the scope of this solution.
6. Applicability 6. Applicability
The method described in this document can be easily extended to The method described in this document can be easily extended to
point-to-point (p2p) links. However, an implementation may continue point-to-point (P2P) links. However, an implementation may continue
to apply the method described in [LDP-IGP-SYNC] to p2p links but to apply the method described in [LDP-IGP-SYNC] to P2P links but
apply the method described in this document to broadcast networks. apply the method described in this document to broadcast networks.
Both methods can co-exist in a network. Both methods can coexist in a network.
The techniques used in this document's solution enable LDP IGP The techniques used in this document's solution enable LDP IGP
synchronization in many scenarios where one end of the IGP adjacency synchronization in many scenarios where one end of the IGP adjacency
does not support any LDP IGP sync method. This is an optional benefit does not support any LDP IGP sync method. This is an optional
and is for further study. Some ways to apply this technique to benefit and is for further study. Some ways to apply this technique
achieve that benefit are discussed in Appendix B. to achieve that benefit are discussed in Appendix B.
7. 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].
Note that in [LDP-IGP-SYNC] when a link is advertised with high Note that in [LDP-IGP-SYNC], when a link is advertised with a high
metric, an alternate path with a large number of hops can result in metric, an alternate path with a large number of hops can result in
the end-to-end path having more than 255 hops and thus result in the end-to-end path having more than 255 hops and thus result in
unreachability. This fact could be exploited if control of metrics unreachability. This fact could be exploited if control of metrics
falls into the hands of an attacker. falls into the hands of an attacker.
This problem can even exist in a plain IP network with a link-state This problem can even exist in a plain IP network with a link-state
IGP. If the directly connected path has a higher metric than an IGP. If the directly connected path has a higher metric than an
alternate path with TTL greater than 255 hops then the standard alternate path with Time to Live (TTL) greater than 255 hops, then
shortest path first algorithm will conclude that the shortest path is the standard SPF algorithm will conclude that the shortest path is
the alternate path although the neighboring node is unreachable the alternate path although the neighboring node is unreachable
through this path. In this case the link is advertised with its through this path. In this case, the link is advertised with its
normal metric yet there is unreachability in the network. Thus, this normal metric yet there is unreachability in the network. Thus, this
document does not introduce any new issues beyond those in a standard document does not introduce any new issues beyond those in a standard
IGP-based IP network, and operators need to apply policy and security IGP-based IP network, and operators need to apply policy and security
to the techniques used to determine and distribute the metrics used to the techniques used to determine and distribute the metrics used
on links in their networks. on links in their networks.
8. IANA Considerations 8. Conclusions
This document has no actions for IANA.
9. Conclusions
This document complements [LDP-IGP-SYNC] by providing a solution to This document complements [LDP-IGP-SYNC] by providing a solution to
achieve LDP IGP synchronization for broadcast networks. It can also achieve LDP IGP synchronization for broadcast networks. It can also
co-exist with that solution in a network that has a combination of coexist with that solution in a network that has a combination of P2P
p2p links and broadcast networks. It can also be introduced into a links and broadcast networks. It can also be introduced into a
network without backward compatibility issues. The solution in this network without backward compatibility issues. The solution in this
document can also be used exclusively to achieve LDP IGP document can also be used exclusively to achieve LDP IGP
synchronization since this solution applies to both p2p links as well synchronization since this solution applies to both P2P links and
as broadcast networks. broadcast networks.
This solution also has useful properties that can be optionally used This solution also has useful properties that can be optionally used
to achieve LDP IGP synchronization when only one end of the IGP to achieve LDP IGP synchronization when only one end of the IGP
adjacency supports this solution but the other end supports neither adjacency supports this solution but the other end supports neither
this solution nor the one in [LDP-IGP-SYNC]. this solution nor the one in [LDP-IGP-SYNC].
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[LDP-IGP-SYNC] Jork, M., et al, "LDP IGP Synchronization", RFC 5443, [LDP-IGP-SYNC]
March 2009. Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, March 2009.
[LDP] Andersson, L., et al, "LDP Specification", RFC 5036, [LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
October 2007. "LDP Specification", RFC 5036, October 2007.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[ISIS] International Organization for Standardization, [IS-IS] International Organization for Standardization,
"Intermediate system to intermediate system intra-domain- "Intermediate System to Intermediate System intra-domain
routing routine information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO connectionless-mode network service (ISO 8473)", ISO
Standard 10589, 1992. Standard 10589, 2002.
10.2. Informative References 9.2. Informative References
[LDP-EOL] Asati, R., et al, "Signaling LDP Label Advertisement [LDP-EOL] Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
Completion", RFC 5919, June 2010. "Signaling LDP Label Advertisement Completion", RFC 5919,
August 2010.
11. Acknowledgements Acknowledgments
The authors would like to thank Luyuan Fang, Mikael Abrahamsson, Ben The authors would like to thank Luyuan Fang, Mikael Abrahamsson, Ben
Niven-Jenkins, Bruno Decraene, Jeff Tantsura and Acee Lindem for Niven-Jenkins, Bruno Decraene, Jeff Tantsura, and Acee Lindem for
their review and useful comments. their review and useful comments.
Appendix A. Computation of 'cut-edge' Appendix A. Computation of "Cut-Edge"
A 'cut-edge' can be computed during an intra-area SPF run or by using 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 results of the previous SPF run. If an SPF run was scheduled but is
pending execution, that SPF MUST be executed immediately before any pending execution, that SPF MUST be executed immediately before any
procedure checks whether an interface is a 'cut-edge'. procedure checks whether an interface is a "cut-edge".
An interface is considered a 'cut-edge' if during intra-area SPF An interface is considered a "cut-edge" if, during intra-area SPF
(using Dijkstra's algorithm - see [OSPF] sec 16) there is no (using Dijkstra's algorithm described in Section 16.1 of [OSPF]),
alternate path for the directly connected network. Alternately, lack there is no alternate path for the directly connected network.
of connectivity to the router-id of a directly connected peer via an Alternately, a "cut-edge" can be detected by the last run of SPF if
alternate path as detected by the last run of SPF can be used. The there is a lack of connectivity to the router-id of a directly
router-id can be known during the adjacency bring-up process. connected peer via an alternate path. The router-id can be known
during the adjacency bring-up process.
A 'cut-edge' computation should not require any extra SPF runs. It A "cut-edge" computation should not require any extra SPF runs. It
should not increase the algorithmic complexity of SPF. should not increase the algorithmic complexity of SPF.
Appendix B. Sync without support at one end Appendix B. Sync without Support at One End
A useful property of the solution described in this document is that A useful property of the solution described in this document is that
LDP IGP synchronization is achievable in many scenarios where one end LDP IGP synchronization is achievable in many scenarios where one end
of the IGP adjacency does not support any LDP IGP sync method. 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 For P2P links (or broadcast links on which the IGP operates in P2P
mode) the applicability is straightforward. An IGP can establish a 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 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 mode. When a P2P adjacency comes up, the end of the adjacency that
supports the solution in this document would not advertise the link 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 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 until LDP becomes operational. Hence, neither of the two routers
have IGP next-hop as the other router unless the link is a 'cut- will have IGP next-hop as the other router unless the link is a
edge'. Consider Figure 1 modified such that the broadcast network is "cut-edge". Consider Figure 1 modified such that the broadcast
replaced by p2p links between each of A, B, C and E. Say link A-B is network is replaced by P2P links between each of A, B, C, and E. Say
coming up but only A has implemented the solution in this document link A-B is coming up, but only A has implemented the solution in
whereas B has implemented neither the solution in this document nor this document whereas B has implemented neither the solution in this
the solution in [LDP-IGP-SYNC]. Since A's LSA does not advertise a document nor the solution in [LDP-IGP-SYNC]. Since A's LSA does not
link to B until LDP is operational, B does not have A as next-hop. advertise a link to B until LDP is operational, B does not have A as
After LDP is operational, A advertises the link to B in its LSA. next-hop. After LDP is operational, A advertises the link to B in
Hence there is no traffic loss due to LDP LSP not being present. its LSA. Hence, there is no traffic loss due to LDP LSP not being
present.
For broadcast networks the applicability is not straightforward and For broadcast networks, the applicability is not straightforward and
should be considered a topic for future study. One way is for the DR should be considered a topic for future study. One way is for the
to stop advertising the link in the pseudo-node to the router whose designated router (DR) to stop advertising the link in the pseudonode
link is coming up until LDP is operational. to the router whose link is coming up until LDP is operational.
Authors' Addresses Authors' Addresses
Sriganesh Kini Sriganesh Kini (editor)
Ericsson Ericsson
300 Holger Way, San Jose, CA 95134 300 Holger Way
San Jose, CA 95134
EMail: sriganesh.kini@ericsson.com EMail: sriganesh.kini@ericsson.com
Wenhu Lu Wenhu Lu (editor)
Ericsson Ericsson
300 Holger Way, San Jose, CA 95134 300 Holger Way
San Jose, CA 95134
EMail: wenhu.lu@ericsson.com EMail: wenhu.lu@ericsson.com
 End of changes. 65 change blocks. 
217 lines changed or deleted 210 lines changed or added

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