draft-ietf-mpls-ldp-igp-sync-bcast-02.txt   draft-ietf-mpls-ldp-igp-sync-bcast-03.txt 
MPLS Working Group S. Kini (Ed) MPLS Working Group S. Kini (Ed)
Internet Draft W. Lu (Ed) Internet Draft W. Lu (Ed)
Intended status: Standards Track Ericsson Intended Status: Standards Track Ericsson
Expires: November 2010 May 10, 2010 Expires: January 2011 July 2, 2010
LDP IGP Synchronization for broadcast networks LDP IGP Synchronization for broadcast networks
draft-ietf-mpls-ldp-igp-sync-bcast-02.txt draft-ietf-mpls-ldp-igp-sync-bcast-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with the
the provisions of BCP 78 and BCP 79. 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 Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet-Drafts as reference
Drafts as reference material or to cite them other than as "work material or to cite them other than as "work in progress."
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 November 10, 2010. This Internet-Draft will expire on January 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 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 carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided the Trust Legal Provisions and are provided without warranty as
without warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
LDP IGP Synchronization ([LDP-IGP-SYNC]) describes a mechanism to RFC 5443 describes a mechanism to achieve LDP IGP Synchronization to
prevent black-holing traffic (e.g. VPN) when an interior gateway prevent black-holing traffic (e.g. VPN) when an interior gateway
protocol (IGP) is operational on a link but Label Distribution protocol (IGP) is operational on a link but Label Distribution
Protocol (LDP) is not. If this mechanism is applied to broadcast Protocol (LDP) is not. If this mechanism is applied to broadcast
links that have more than one LDP/IGP peer, the cost-out 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 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 individual peer. When a new LDP peer comes up on a broadcast network,
network, this can result in loss of traffic through other this can result in loss of traffic through other established peers on
established peers on that network. This document describes a that network. This document describes a mechanism to address that
mechanism to address that use-case without dropping traffic. The use-case without dropping traffic. The mechanism does not introduce
mechanism does not introduce any protocol changes. any protocol message changes.
Table of Contents Table of Contents
1. Introduction ..................................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document .............................3 2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. Problem Statement .............................................3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution ......................................................5 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Scope .........................................................7 5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Applicability .................................................7 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations .......................................7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations ...........................................7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Conclusions ...................................................7 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References ...................................................8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References ....................................8 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References ..................................8 10.2. Informative References . . . . . . . . . . . . . . . . . 7
11. Acknowledgments ..............................................9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Computation of 'cut-edge' ...........................10 Appendix A. Computation of 'cut-edge' . . . . . . . . . . . . . . 9
Appendix B. Sync without support at one end .....................11 Appendix B. Sync without support at one end . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In [LDP-IGP-SYNC], when [LDP] is not fully operational on a link, In RFC 5443 ([LDP-IGP-SYNC]), when [LDP] is not fully operational on
the IGP advertises the link with maximum cost to avoid any a link, the IGP advertises the link with maximum cost to avoid any
transit traffic on the link if possible. When LDP becomes transit traffic on the link if possible. When LDP becomes operational
operational i.e., all the label bindings have been exchanged, the i.e., all the label bindings have been exchanged, the link is
link is advertised with its correct cost. This tries to ensure advertised with its correct cost. This tries to ensure that all along
that all along the IGP shortest path, the LDP LSP is available. the IGP shortest path, the LDP LSP is available. The mechanisms in
The mechanisms in [LDP-IGP-SYNC] have limitations when applied to [LDP-IGP-SYNC] have limitations when applied to a broadcast link.
a broadcast link. These are described in section 3. A solution is These are described in section 3. A solution is defined in section 4.
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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described in document are to be interpreted as described in [RFC2119].
[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 separate cost to each peer on the broadcast network. The operation of
operation of the mechanism in [LDP-IGP-SYNC] is analyzed using the mechanism in [LDP-IGP-SYNC] is analyzed using the sample topology
the sample topology of Figure 1 below where routers A, B, C and E of Figure 1 below where routers A, B, C and E are attached to a
are attached to a common broadcast network. Say all links in that common broadcast network. Say all links in that topology have a cost
topology have a cost of 1 except the link A-PE3 that has a cost of 1 except the link A-PE3 that has a cost of 10. The use-case when
of 10. The use-case when router B's link to the broadcast network router B's link to the broadcast network comes up is analyzed. Before
comes up is analyzed. Before that link comes up, traffic between that link comes up, traffic between PE1 and PE2 flows along the bi-
PE1 and PE2 flows along the bi-directional path PE1-A-C-D-PE2 and directional path PE1-A-C-D-PE2 and traffic between PE1 and PE3 flows
traffic between PE1 and PE3 flows along the bi-directional path along the bi-directional path PE1-A-E-PE3.
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 4, line 26
| | | |
| | +---+ | | +---+
| |----| 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
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 In one interpretation of the applicability of [LDP-IGP-SYNC] to
the maximum cost advertisement to be reverted by all routers broadcast networks, when a new router is discovered on a broadcast
after LDP peering between all the routers on the broadcast network, that network should avoid transit traffic till LDP becomes
network is operational. This is non-trivial and needs co- operational between all routers on that network. This can be achieved
ordination between all the routers. 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 This interpretation has the additional complexity of requiring the
[LDP-IGP-SYNC] to broadcast networks, only the router whose link maximum cost advertisement to be reverted by all routers after LDP
to the broadcast network comes up, advertises maximum cost for peering between all the routers on the broadcast network is
that link but other routers continue to advertise the normal operational. This is non-trivial and needs co-ordination between all
cost. In Figure 1 when B's link to the broadcast network comes the routers.
up, it advertises a high cost to the broadcast network. After the
IGP has converged but the LDP peering A-B is not yet operational,
A will have B as the next-hop for PE2 and will not have a LDP LSP
path to PE2. Since A's cost to reach B not high, A-B-PE2 becomes
the shortest path. VPN traffic from PE1 to PE2 will be dropped at
A.
4. Solution 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 problem described above exists because the link-state 4. Solution
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 solution proposed below removes the link that is coming up The problem described above exists because the link-state database
from the LSDB unless absolutely necessary. Only the router whose (LSDB) of the IGP does not describe a link coming up on a broadcast
link is coming up plays a role in ensuring this. The other network with a high bi-directional cost to all other routers on that
routers on the broadcast network are not involved. The following broadcast network. A broadcast network is advertised as a pseudo-node
text describes this in more detail. 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.
During the intra-area SPF algorithm execution, an additional The solution proposed below removes the link that is coming up from
computation is made to detect an alternate path to a directly the LSDB unless absolutely necessary. Only the router whose link is
connected network that does not have any IGP adjacencies. 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.
If a router has a directly connected network that does not have During the intra-area SPF algorithm execution, an additional
an alternate path to reach it, then the interface to that network computation is made to detect an alternate path to a directly
is a 'cut-edge' in the topology for that router. When a 'cut- connected network that does not have any IGP adjacencies.
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 If a router has a directly connected network that does not have an
broadcast network is coming up and the LSA is about to be updated alternate path to reach it, then the interface to that network is a
with a link to the pseudo-node of the broadcast interface, a 'cut-edge' in the topology for that router. When a 'cut-edge' goes
check is made whether that interface is a 'cut-edge'. If it is down, the network is partitioned into two disjoint sub-graphs. This
not a 'cut-edge' then the updating of the LSA with that link to property of whether or not an interface is a 'cut-edge' is used when
the pseudo-node is postponed until LDP is operational with all an IGP adjacency comes up on that interface. The method to determine
the LDP peers on that broadcast interface. After LDP is whether an interface is a 'cut-edge' is described in Appendix A.
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 During IGP procedures when the router's first adjacency to the
Type 2' (link to transit network) for that subnet, until LDP is broadcast network is coming up and the LSA is about to be updated
operational with all neighboring routers on that subnet. with a link to the pseudo-node of the broadcast interface, a check is
made whether that interface is a 'cut-edge'. If it is not a 'cut-
edge' then the updating of the LSA with that link to the pseudo-node
is postponed until LDP is operational with all the LDP peers on that
broadcast interface. After LDP is operational, the LSA is updated
with that link to the pseudo-node (and the LSA is flooded). If the
interface is a 'cut-edge' then the updating of the LSA MUST NOT be
delayed by LDP's operational state. Note that the IGP and LDP
adjacency bring-up procedures are unchanged. The conditional check
whether the interface is a 'cut-edge' must be done just before the
adjacency is about to be reflected in the LSA.
Similarly, if the IGP is [ISIS], the 'Link State PDU' is updated If the IGP is [OSPF], the Router-LSA is not updated with a 'Link Type
with an 'IS Reachability TLV' (or an 'Extended IS Reachability 2' (link to transit network) for that subnet, until LDP is
TLV') to the pseudo-node after LDP is operational with all operational with all neighboring routers on that subnet.
neighboring routers on that subnet.
Note that this solution can be introduced in a gradual manner in Similarly, if the IGP is [ISIS], the 'Link State PDU' is updated with
a network without any backward compatibility issues. 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.
5. Scope Note that this solution can be introduced in a gradual manner in a
network without any backward compatibility issues.
This document is agnostic to the method that detects LDP to be 5. Scope
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 This document is agnostic to the method that detects LDP to be
on some interfaces are not specific to the method described in operational with a neighbor. It does not define any new method to
this document and are considered outside the scope of this detect that LDP is operational. At the time of publishing this
solution. document [LDP-EOL] seems to be the preferred method.
6. Applicability 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 (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 The method described in this document can be easily extended to
synchronization in many scenarios where one end of the IGP point-to-point (p2p) links. However, an implementation may continue
adjacency does not support any LDP IGP sync method. This is an to apply the method described in [LDP-IGP-SYNC] to p2p links but
optional benefit and is for further study. Some ways to apply apply the method described in this document to broadcast networks.
this technique to achieve that benefit are discussed in Appendix Both methods can co-exist in a network.
B.
7. Security Considerations 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.
This document does not introduce any new security considerations 7. Security Considerations
beyond those already described in [LDP-IGP-SYNC]. This document does not introduce any new security considerations
beyond those already described in [LDP-IGP-SYNC].
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Conclusions 9. Conclusions
This document complements [LDP-IGP-SYNC] by providing a solution This document complements [LDP-IGP-SYNC] by providing a solution to
to achieve LDP IGP synchronization for broadcast networks. It can achieve LDP IGP synchronization for broadcast networks. It can also
also co-exist with that solution in a network that has a co-exist with that solution in a network that has a combination of
combination of p2p links and broadcast networks. It can also be p2p links and broadcast networks. It can also be introduced into a
introduced into a network without backward compatibility issues. network without backward compatibility issues. The solution in this
The solution in this document can also be used exclusively to document can also be used exclusively to achieve LDP IGP
achieve LDP IGP synchronization since this solution applies to synchronization since this solution applies to both p2p links as well
both p2p links as well as broadcast networks. as broadcast networks.
This solution also has useful properties that can be optionally This solution also has useful properties that can be optionally used
used to achieve LDP IGP synchronization when only one end of the to achieve LDP IGP synchronization when only one end of the IGP
IGP adjacency supports this solution but the other end supports adjacency supports this solution but the other end supports neither
neither this solution nor the one in [LDP-IGP-SYNC]. this solution nor the one in [LDP-IGP-SYNC].
10. References 10. References
10.1. Normative References 10.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 [LDP-IGP-SYNC] Jork, M., et al, "LDP IGP Synchronization", RFC 5443,
5443, March 2009. March 2009.
10.2. Informative References
[LDP] Andersson, L., et al, "LDP Specification", RFC 5036, [LDP] Andersson, L., et al, "LDP Specification", RFC 5036,
October 2007. October 2007.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
1998.
[ISIS] International Organization for Standardization,
"Intermediate system to intermediate system intra-
domain-routing routine information exchange protocol
for use in conjunction with the protocol for providing
the connectionless-mode Network Service (ISO 8473)",
ISO Standard 10589, 1992.
[LDP-EOL] Asati, R., et al, "Signaling LDP Label Advertisement
Completion", draft-ietf-mpls-ldp-end-of-lib-04, Work in
progress, August 2009.
11. Acknowledgments [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.
The authors would like to thank Luyuan Fang, Mikael Abrahamsson, 10.2. Informative References
Ben Niven-Jenkins, Bruno Decraene, Jeff Tantsura and Acee Lindem
for their review and useful comments.
This document was prepared using 2-Word-v2.0.template.dot. [LDP-EOL] Asati, R., et al, "Signaling LDP Label Advertisement
Completion", RFC 5919, June 2010.
Appendix A. Computation of 'cut-edge' 11. Acknowledgements
A 'cut-edge' can be computed during an intra-area SPF run or by The authors would like to thank Luyuan Fang, Mikael Abrahamsson, Ben
using results of the previous SPF run. If a SPF run was scheduled Niven-Jenkins, Bruno Decraene, Jeff Tantsura and Acee Lindem for
but is pending execution, that SPF MUST be executed immediately their review and useful comments.
before any procedure checks whether an interface is a 'cut-edge'.
An interface is considered a 'cut-edge' if during intra-area SPF Appendix A. Computation of 'cut-edge'
(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. A 'cut-edge' can be computed during an intra-area SPF run or by using
It should not increase the algorithmic complexity of SPF. 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'.
Appendix B. Sync without support at one end 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 useful property of the solution described in this document is A 'cut-edge' computation should not require any extra SPF runs. It
that LDP IGP synchronization is achievable in many scenarios should not increase the algorithmic complexity of SPF.
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 Appendix B. Sync without support at one end
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 A useful property of the solution described in this document is that
and should be considered a topic for future study. One way is for LDP IGP synchronization is achievable in many scenarios where one end
the DR to stop advertising the link in the pseudo-node to the of the IGP adjacency does not support any LDP IGP sync method.
router whose link is coming up until LDP is operational.
Authors' Addresses 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.
Sriganesh Kini For broadcast networks the applicability is not straightforward and
Ericsson should be considered a topic for future study. One way is for the DR
300 Holger Way, San Jose, CA 95134 to stop advertising the link in the pseudo-node to the router whose
link is coming up until LDP is operational.
Email: sriganesh.kini@ericsson.com Authors' Addresses
Wenhu Lu Sriganesh Kini
Ericsson Ericsson
300 Holger Way, San Jose, CA 95134 300 Holger Way, San Jose, CA 95134
EMail: sriganesh.kini@ericsson.com
Email: wenhu.lu@ericsson.com Wenhu Lu
Ericsson
300 Holger Way, San Jose, CA 95134
EMail: wenhu.lu@ericsson.com
 End of changes. 69 change blocks. 
290 lines changed or deleted 268 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/