draft-ietf-mpls-ldp-igp-sync-bcast-04.txt   draft-ietf-mpls-ldp-igp-sync-bcast-05.txt 
MPLS Working Group S. Kini (Ed) MPLS Working Group S. Kini (Ed)
Internet Draft W. Lu (Ed) Internet Draft W. Lu (Ed)
Updates: 5443 (if approved) Ericsson Updates: 5443 (if approved) Ericsson
Intended Status: Informational September 13, 2010 Intended Status: Informational October 25, 2010
Expires: March 2011 Expires: April 2011
LDP IGP Synchronization for broadcast networks LDP IGP Synchronization for broadcast networks
draft-ietf-mpls-ldp-igp-sync-bcast-04.txt draft-ietf-mpls-ldp-igp-sync-bcast-05.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 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.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 March 17, 2011. This Internet-Draft will expire on April 28, 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
skipping to change at page 5, line 15 skipping to change at page 5, line 15
the routers. the routers.
In another alternative interpretation of the applicability of [LDP- In another alternative interpretation of the applicability of [LDP-
IGP-SYNC] to broadcast networks, only the router whose link to the IGP-SYNC] to broadcast networks, only the router whose link to the
broadcast network comes up, advertises maximum cost for that link but broadcast network comes up, advertises maximum cost for that link but
other routers continue to advertise the normal cost. In Figure 1 when 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 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 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 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 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 B is not high, A-B-PE2 becomes the shortest path. VPN traffic from
to PE2 will be dropped at A. 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 pseudo-node
containing a list of routers that the broadcast network is connected 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 to and the cost of all these links from the pseudo-node to each
router is zero when computing SPF. 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 this
in more detail. 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.
skipping to change at page 9, line 13 skipping to change at page 9, line 13
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 a 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) there is no alternate path for the (using Dijkstra's algorithm - see [OSPF] sec 16) there is no
directly connected network. Alternately, lack of connectivity to the alternate path for the directly connected network. Alternately, lack
router-id of a directly connected peer via an alternate path as of connectivity to the router-id of a directly connected peer via an
detected by the last run of SPF can be used. The router-id can be alternate path as detected by the last run of SPF can be used. The
known during the adjacency bring-up process. 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.
 End of changes. 6 change blocks. 
12 lines changed or deleted 12 lines changed or added

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