draft-ietf-mpls-ldp-igp-sync-bcast-01.txt   draft-ietf-mpls-ldp-igp-sync-bcast-02.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: September 2010 March 22, 2010 Expires: November 2010 May 10, 2010
LDP IGP Synchronization for broadcast networks LDP IGP Synchronization for broadcast networks
draft-ietf-mpls-ldp-igp-sync-bcast-01.txt draft-ietf-mpls-ldp-igp-sync-bcast-02.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 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.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference 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 September 22, 2010. This Internet-Draft will expire on November 10, 2010.
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 2, line 23 skipping to change at page 2, line 31
links that have more than one LDP/IGP peer, the cost-out 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 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, this can result in loss of traffic through other network, this can result in loss of traffic through other
established peers on that network. This document describes a established peers on that network. This document describes a
mechanism to address that use-case without dropping traffic. The mechanism to address that use-case without dropping traffic. The
mechanism does not introduce any protocol changes. mechanism does not introduce any protocol changes.
Table of Contents Table of Contents
1. Introduction ..................................................2 1. Introduction ..................................................3
2. Conventions used in this document .............................3 2. Conventions used in this document .............................3
3. Problem Statement .............................................4 3. Problem Statement .............................................3
4. Solution ......................................................5 4. Solution ......................................................5
5. Scope .........................................................7 5. Scope .........................................................7
6. Applicability .................................................7 6. Applicability .................................................7
7. Security Considerations .......................................7 7. Security Considerations .......................................7
8. IANA Considerations ...........................................7 8. IANA Considerations ...........................................7
9. Conclusion ....................................................7 9. Conclusions ...................................................7
10. References ...................................................8 10. References ...................................................8
10.1. Normative References ....................................8 10.1. Normative References ....................................8
10.2. Informative References ..................................8 10.2. Informative References ..................................8
11. Acknowledgments ..............................................8 11. Acknowledgments ..............................................9
Appendix A. Computation of 'cut-edge' ............................9 Appendix A. Computation of 'cut-edge' ...........................10
Appendix B. Sync without support at one end .....................10 Appendix B. Sync without support at one end .....................11
1. Introduction 1. Introduction
In [LDP-IGP-SYNC], when LDP is not fully operational on a link, In [LDP-IGP-SYNC], when [LDP] is not fully operational on a link,
the IGP advertises the link with maximum cost to avoid any 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 i.e., all the label bindings have been exchanged, the operational i.e., all the label bindings have been exchanged, the
link is advertised with its correct cost. This tries to ensure link is advertised with its correct cost. This tries to ensure
that all along the IGP shortest path, the LDP LSP is available. that all along the IGP shortest path, the LDP LSP is available.
The mechanisms in [LDP-IGP-SYNC] have limitations when applied to The mechanisms in [LDP-IGP-SYNC] have limitations when applied to
a broadcast link. These are described in section 3. A solution is a broadcast link. 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", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
skipping to change at page 4, line 16 skipping to change at page 3, line 37
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 the mechanism in [LDP-IGP-SYNC] is analyzed using 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 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 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 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 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 comes up is analyzed. Before that link comes up, traffic between
PE1 and PE2 flows along the bi-directional path PE1-A-C PE1 and PE2 flows along the bi-directional path PE1-A-C-D-PE2 and
-D-PE2 and traffic between PE1 and PE3 flows along the bi- traffic between PE1 and PE3 flows along the bi-directional path
directional path PE1-A-E-PE3. PE1-A-E-PE3.
| | +---+ +---+
| +---+ +---+ |----| B |-----------|PE2|
|----| B |-----------|PE2| | +---+ +---+
| +---+ +---+ +---+ +---+ | |
+---+ +---+ | | |PE1|----| A |----| |
|PE1|----| A |----| | +---+ +---+ | |
+---+ +---+ | | | | +---+ +---+ |
| | +---+ +---+ | | |----| C |----| D |----+
| |----| C |----| D |----+ | | +---+ +---+
| | +---+ +---+ | |
| | | |
| | | |
| | | | +---+
| | +---+ | |----| 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 networks, when a new router is discovered on a
broadcast network, that network should avoid transit traffic till broadcast network, that network should avoid transit traffic till
LDP becomes operational between all routers on that network. This LDP becomes operational between all routers on that network. This
can be achieved by having all the attached routers advertise can be achieved by having all the attached routers advertise
maximum cost to that network. This should result in traffic that maximum cost to that network. This should result in traffic that
is being sent via that broadcast network to be diverted. However, is being sent via that broadcast network to be diverted. However,
traffic might be inadvertently diverted to the link that just traffic might be inadvertently diverted to the link that just
came up. Till LDP becomes operational, that traffic will be came up. Till LDP becomes operational, that traffic will be
skipping to change at page 7, line 41 skipping to change at page 7, line 41
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].
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Conclusion 9. Conclusions
This document complements [LDP-IGP-SYNC] by providing a solution This document complements [LDP-IGP-SYNC] by providing a solution
to achieve LDP IGP synchronization for broadcast networks. It can to achieve LDP IGP synchronization for broadcast networks. It can
also co-exist with that solution in a network that has a also co-exist with that solution in a network that has a
combination of p2p links and broadcast networks. It can also be combination of p2p links and broadcast networks. It can also be
introduced into a network without backward compatibility issues. introduced into a network without backward compatibility issues.
The solution in this document can also be used exclusively to The solution in this document can also be used exclusively to
achieve LDP IGP synchronization since this solution applies to achieve LDP IGP synchronization since this solution applies to
both p2p links as well as broadcast networks. both p2p links as well as broadcast networks.
This solution also has useful properties that can be optionally This solution also has useful properties that can be optionally
used to achieve LDP IGP synchronization when only one end of the used to achieve LDP IGP synchronization when only one end of the
IGP adjacency supports this solution but the other end supports IGP adjacency supports this solution but the other end supports
neither this solution nor the one in [LDP-IGP-SYNC]. neither this solution nor the one in [LDP-IGP-SYNC].
10. References 10. References
skipping to change at page 8, line 26 skipping to change at page 8, line 28
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, March 2009. 5443, March 2009.
10.2. Informative References 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 1998. [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[ISIS] International Organization for Standardization, [ISIS] International Organization for Standardization,
"Intermediate system to intermediate system intra- "Intermediate system to intermediate system intra-
domain-routing routine information exchange protocol domain-routing routine information exchange protocol
for use in conjunction with the protocol for providing for use in conjunction with the protocol for providing
the connectionless-mode Network Service (ISO 8473)", the connectionless-mode Network Service (ISO 8473)",
ISO Standard 10589, 1992. ISO Standard 10589, 1992.
[LDP-EOL] Asati, R., et al, "Signaling LDP Label Advertisement [LDP-EOL] Asati, R., et al, "Signaling LDP Label Advertisement
Completion", draft-ietf-mpls-ldp-end-of-lib-04, Work in Completion", draft-ietf-mpls-ldp-end-of-lib-04, Work in
progress, August 2009. progress, August 2009.
skipping to change at page 9, line 9 skipping to change at page 10, line 9
The authors would like to thank Luyuan Fang, Mikael Abrahamsson, The authors would like to thank Luyuan Fang, Mikael Abrahamsson,
Ben Niven-Jenkins, Bruno Decraene, Jeff Tantsura and Acee Lindem Ben Niven-Jenkins, Bruno Decraene, Jeff Tantsura and Acee Lindem
for their review and useful comments. for their review and useful comments.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
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 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 using results of the previous SPF run. If a SPF run was scheduled
but is pending execution, that SPF must be executed immediately but is pending execution, that SPF MUST be executed immediately
before any procedure checks whether an interface is a 'cut-edge'. before any 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) there is no alternate path for the
directly connected network. Alternately, lack of connectivity to directly connected network. Alternately, lack of connectivity to
the router-id of a directly connected peer via an alternate path 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 as detected by the last run of SPF can be used. The router-id can
be known during the adjacency bring-up process. be known during the adjacency bring-up process.
A 'cut-edge' computation should not require any extra SPF runs. A 'cut-edge' computation should not require any extra SPF runs.
 End of changes. 18 change blocks. 
42 lines changed or deleted 40 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/