draft-ietf-mpls-ldp-igp-sync-02.txt		draft-ietf-mpls-ldp-igp-sync-03.txt
	Network Working Group M. Jork		Network Working Group M. Jork
	Internet Draft NextPoint Networks		Internet Draft NextPoint Networks
	Category: Informational Alia Atlas		Category: Informational Alia Atlas
	Expires: December 2008 British Telecom		Expires: May 2008 British Telecom
	L. Fang		L. Fang
	Cisco Systems, Inc.		Cisco Systems, Inc.
	June 28, 2008		November 3, 2008
	LDP IGP Synchronization		LDP IGP Synchronization
	draft-ietf-mpls-ldp-igp-sync-02.txt		draft-ietf-mpls-ldp-igp-sync-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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
	skipping to change at page 2, line 4		skipping to change at page 2, line 4
	Abstract		Abstract
	In certain networks there is a dependency on edge-to-edge LSPs setup		In certain networks there is a dependency on edge-to-edge LSPs setup
	by LDP, e.g. networks that are used for MPLS VPN applications. For		by LDP, e.g. networks that are used for MPLS VPN applications. For
	such applications it is not possible to rely on IP forwarding if the		such applications it is not possible to rely on IP forwarding if the
	MPLS LSP is not operating appropriately. Blackholing of labeled		MPLS LSP is not operating appropriately. Blackholing of labeled
	traffic can occur in situations where the IGP is operational on a		traffic can occur in situations where the IGP is operational on a
	link but LDP is not operational on that link. While the link could		link but LDP is not operational on that link. While the link could
	still be used for IP forwarding, it is not useful for MPLS		still be used for IP forwarding, it is not useful for MPLS
			LDP IGP Synchronization November 2008
	forwarding, for example, MPLS VPN; BGP route free core; or IP		forwarding, for example, MPLS VPN; BGP route free core; or IP
	address carried in the packet is out of the RFC1918 space. This		address carried in the packet is out of the RFC1918 space. This
	document describes a mechanism to avoid traffic loss due to this		document describes a mechanism to avoid traffic loss due to this
	condition without introducing any protocol changes.		condition without introducing any protocol changes.
	Table of Contents		Table of Contents
	1. Introduction..................................................2		1. Introduction..................................................2
	2. Proposed Solution.............................................3		2. Proposed Solution.............................................3
	3. Applicability.................................................4		3. Applicability.................................................4
	4. Interaction With TE Tunnels...................................5		4. Interaction With TE Tunnels...................................5
	5. Security Considerations.......................................5		5. Security Considerations.......................................5
	6. IANA Considerations...........................................5		6. IANA Considerations...........................................5
	7. Normative References..........................................6		7. Normative References..........................................6
	8. Informational References......................................6		8. Informational References......................................6
	9. Author's Addresses............................................6		9. Author's Addresses............................................6
	10. Acknowledgements............................................8		10. Acknowledgements.............................................8
	Conventions used in this document		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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC2119 [RFC		this document are to be interpreted as described in RFC2119 [RFC
	2119].		2119].
	1. Introduction		1. Introduction
	LDP [RFC5036] establishes MPLS LSPs along the shortest path to a		LDP [RFC5036] establishes MPLS LSPs along the shortest path to a
	destination as determined by IP forwarding. In a common network		destination as determined by IP forwarding. In a common network
	design, LDP is used to provide label switched paths throughout the		design, LDP is used to provide label switched paths throughout the
	complete network domain covered by an IGP such as OSPF [RFC2328] or		complete network domain covered by an IGP such as OSPF [RFC2328] or
	IS-IS [ISO.10589.1992], i.e. all links in the domain have IGP as		IS-IS [ISO.10589.1992], i.e. all links in the domain MAY have IGP
	well as LDP adjacencies.		as well as LDP adjacencies.
	A variety of services a network provider may want to deploy over an		A variety of services a network provider may want to deploy over an
	LDP enabled network depend on the availability of edge to edge		LDP enabled network depend on the availability of edge to edge
	label switched paths. In a L2 or L3 VPN scenario for example, a		label switched paths. In a L2 or L3 VPN scenario for example, a
	given PE router relies on the availability of a complete MPLS		given PE router relies on the availability of a complete MPLS
	forwarding path to the other PE routers for the VPNs it serves.		forwarding path to the other PE routers for the VPNs it serves.
	This means that along the IP shortest path from one PE router to		This means that along the IP shortest path from one PE router to
	the other, all the links need to have operational LDP sessions and		the other, all the links need to have operational LDP sessions and
	the necessary label binding must have been exchanged over those		the necessary label binding must have been exchanged over those
	sessions. If only one link along the IP shortest path is not		sessions. If only one link along the IP shortest path is not
	covered by an LDP session, a blackhole exists and services		covered by an LDP session, a blackhole exists and services
	depending on MPLS forwarding will fail. This might be a transient		depending on MPLS forwarding will fail. This might be a transient
			LDP IGP Synchronization November 2008
	or a persistent error condition. Some of the reasons for it could		or a persistent error condition. Some of the reasons for it could
	be		be
	- A configuration error		- A configuration error
	- An implementation bug		- An implementation bug
	- The link has just come up and has an IGP adjacency but LDP has		- The link has just come up and has an IGP adjacency but LDP has
	either not yet established an adjacency or session or		either not yet established an adjacency or session or
	distributed all the label bindings.		distributed all the label bindings.
	skipping to change at page 3, line 39		skipping to change at page 3, line 41
	This has some similarity to the mechanism specified in [RFC3137]		This has some similarity to the mechanism specified in [RFC3137]
	which allows an OSPF router to advertise that it should not be used		which allows an OSPF router to advertise that it should not be used
	as a transit router. One difference is that [RFC3137] raises the		as a transit router. One difference is that [RFC3137] raises the
	link costs on all (stub) router links, while the mechanism		link costs on all (stub) router links, while the mechanism
	described in here applies on a per-link basis.		described in here applies on a per-link basis.
	In detail: when LDP is not "fully operational" (see below) on a		In detail: when LDP is not "fully operational" (see below) on a
	given link, the IGP will advertise the link with maximum cost to		given link, the IGP will advertise the link with maximum cost to
	avoid any transit traffic over it if possible. In the case of		avoid any transit traffic over it if possible. In the case of
	OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in		OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in
	[RFC3137]. In the case of ISIS, the max matrix value is 0xFFFFFE		[RFC3137]. In the case of ISIS, the max metric value is 2^24-2
	per [RFC 3784]. Note that the link is not just simply removed from		(0xFFFFFE). Indeed, if a link is configured with 2^24-1 (the
	the topology because LDP depends on the IP reachability to		maximum link metric per [RFC3784]) then this link is not advertised
	establish its adjacency and session. Also, if there is no other		in the topology. It is important to keep the link in the topology
	link in the network to reach a particular destination, no		to allow for IP traffic to use the link as a last resort in case of
	additional harm is done by making this link available for IP		massive failure.
	forwarding at maximum cost.
	LDP is considered fully operational on a link when an LDP hello		LDP is considered fully operational on a link when an LDP hello
	adjacency exists on it, a suitable associated LDP session (matching		adjacency exists on it, a suitable associated LDP session (matching
	the LDP Identifier of the hello adjacency) is established to the		the LDP Identifier of the hello adjacency) is established to the
	peer at the other end of the link and all label bindings have been		peer at the other end of the link and all label bindings have been
	exchanged over the session. At the present time, the latter		exchanged over the session. At the present time, the latter
			LDP IGP Synchronization November 2008
	condition can not generally be verified by a router and some		condition can not generally be verified by a router and some
	estimated may have to be used. A simple implementation strategy is		estimated may have to be used. A simple implementation strategy is
	to use a configurable hold down timer to allow LDP session		to use a configurable hold down timer to allow LDP session
	establishment before declaring LDP fully operational. The default		establishment before declaring LDP fully operational. The default
	timer is not defined in this document due to the concerns of the		timer is not defined in this document due to the concerns of the
	large variations of the LIB table size and the equipment		large variations of the LIB table size and the equipment
	capabilities. In addition, this is a current work in progress on LDP		capabilities. In addition, this is a current work in progress on LDP
	End-of-LIB as specified in [LDP End-of-LIB], it enables the LDP		End-of-LIB as specified in [LDP End-of-LIB], it enables the LDP
	speaker to signal the completion of its initial advertisement		speaker to signal the completion of its initial advertisement
	following session establish. When LDP End-of-LIB is implemented, the		following session establish. When LDP End-of-LIB is implemented, the
	skipping to change at page 5, line 5		skipping to change at page 5, line 5
	Example network scenarios that benefit from the mechanism described		Example network scenarios that benefit from the mechanism described
	here are MPLS VPNs and BGP-free core network designs where traffic		here are MPLS VPNs and BGP-free core network designs where traffic
	can only be forwarded through the core when LDP forwarding state is		can only be forwarded through the core when LDP forwarding state is
	available throughout.		available throughout.
	The usefulness of this mechanism also depends on the availability		The usefulness of this mechanism also depends on the availability
	of alternate paths with sufficient bandwidth in the network should		of alternate paths with sufficient bandwidth in the network should
	one link be assigned to the maximum cost due to unavailability of		one link be assigned to the maximum cost due to unavailability of
	LDP service over it.		LDP service over it.
			LDP IGP Synchronization November 2008
	On broadcast links with more than one IGP/LDP peer, the cost-out		On broadcast links with more than one IGP/LDP peer, the cost-out
	procedure can only be applied to the link as a whole and not an		procedure can only be applied to the link as a whole and not an
	individual peer. So a policy decision has to be made whether the		individual peer. So a policy decision has to be made whether the
	unavailability of LDP service to one peer should result in the		unavailability of LDP service to one peer should result in the
	traffic being diverted away from all the peers on the link.		traffic being diverted away from all the peers on the link.
	4. Interaction With TE Tunnels		4. Interaction With TE Tunnels
	In some networks, LDP is used in conjunction with RSVP-TE which sets		In some networks, LDP is used in conjunction with RSVP-TE which sets
	up traffic-engineered tunnels. The path computation for the TE		up traffic-engineered tunnels. The path computation for the TE
	skipping to change at page 6, line 4		skipping to change at page 6, line 4
	LDP is failed and IGP is not should not introduce new security		LDP is failed and IGP is not should not introduce new security
	threats. The operation is internal in the router to allow LDP and		threats. The operation is internal in the router to allow LDP and
	IGP to communicate and react. Making many LDP links unavailable,		IGP to communicate and react. Making many LDP links unavailable,
	however, is a security threat which can cause traffic being dropped		however, is a security threat which can cause traffic being dropped
	due to limited available network capacity. This may be trigged by		due to limited available network capacity. This may be trigged by
	operational error or implementation error. They are considered as		operational error or implementation error. They are considered as
	general Security issues and should follow the current best security		general Security issues and should follow the current best security
	practice.		practice.
	6. IANA Considerations		6. IANA Considerations
			LDP IGP Synchronization November 2008
	This document has no actions for IANA.		This document has no actions for IANA.
	7. Normative References		7. Normative References
	[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,		[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
	and B. Thomas, "LDP Specification", RFC 5036, October 2007.		and B. Thomas, "LDP Specification", RFC 5036, October 2007.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	8. Informational References		8. Informational References
	skipping to change at page 6, line 32		skipping to change at page 6, line 34
	[ISO.10589.1992]International Organization for		[ISO.10589.1992]International Organization for
	Standardization,"Intermediate system to intermediate system intra-		Standardization,"Intermediate system to intermediate system intra-
	domain-routing routine information exchange protocol for use in		domain-routing routine information exchange protocol for use in
	conjunction with the protocol for providing the connectionless-mode		conjunction with the protocol for providing the connectionless-mode
	Network Service (ISO 8473)", ISO Standard 10589, 1992.		Network Service (ISO 8473)", ISO Standard 10589, 1992.
	[LDP-Fail] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and		[LDP-Fail] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and
	Swallow, G., "LDP Failure Detection and Recovery", IEEE		Swallow, G., "LDP Failure Detection and Recovery", IEEE
	Communications Magazine, Vol.42, No.10, October 2004.		Communications Magazine, Vol.42, No.10, October 2004.
	[LDP End-of-LIB] Asati, R., LDP End-of-LIB, draft-asati-mpls-ldp-		[LDP End-of-LIB] Asati, R., LDP End-of-LIB, draft-ietf-mpls-ldp-
	end-of-lib-01.txt, November 2007.		end-of-lib-01.txt, September 2008.
	9. Author's Addresses		9. Author's Addresses
	Markus Jork		Markus Jork
	NextPoint Networks		NextPoint Networks
	3 Fedral St.		3 Fedral St.
	Billerica, MA 01821		Billerica, MA 01821
	USA		USA
	Email: mjork@nextpointnetworks.com		Email: mjork@nextpointnetworks.com
	Alia Atlas		Alia Atlas
	British Telecom		British Telecom
	Email: alia.atlas@bt.com		Email: alia.atlas@bt.com
			LDP IGP Synchronization November 2008
	Luyuan Fang		Luyuan Fang
	Cisco Systems, Inc.		Cisco Systems, Inc.
	300 Beaver Brook Road		300 Beaver Brook Road
	Boxborough, MA 01719		Boxborough, MA 01719
	USA		USA
	Email: lufang@cisco.com		Email: lufang@cisco.com
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology described
	in this document or the extent to which any license under such
	rights might or might not be available; nor does it represent that
	it has made any independent effort to identify any such rights.
	Information on the procedures with respect to rights in RFC
	documents can be found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use
	of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	skipping to change at page 8, line 31		skipping to change at page 8, line 5
	of such proprietary rights by implementers or users of this		of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.		at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
			LDP IGP Synchronization November 2008
	10. Acknowledgements		10. Acknowledgements
	Funding for the RFC Editor function is provided by the IETF		Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).		Administrative Support Activity (IASA).
	The authors would like to thank Loa Andersson for his review and		The authors would like to thank Loa Andersson for his review and
	comments, and thank Bruno Decraene for his in depth discussion,		comments, thank Bruno Decraene for his in depth discussion,
	comments and helpful suggestions.		comments and helpful suggestions, and thank Dave Ward for his AD
			review comments and suggestions.
End of changes. 16 change blocks.
	39 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/