draft-ietf-mpls-ldp-dod-02.txt		draft-ietf-mpls-ldp-dod-03.txt
	Network Working Group T. Beckhaus		Network Working Group T. Beckhaus
	Internet-Draft Deutsche Telekom AG		Internet-Draft Deutsche Telekom AG
	Intended status: Informational B. Decraene		Intended status: Informational B. Decraene
	Expires: January 16, 2013 France Telecom		Expires: February 3, 2013 France Telecom
	K. Tiruveedhula		K. Tiruveedhula
	Juniper Networks		Juniper Networks
	M. Konstantynowicz		M. Konstantynowicz
	L. Martini		L. Martini
	Cisco Systems, Inc.		Cisco Systems, Inc.
	July 15, 2012		August 2, 2012
	LDP Downstream-on-Demand in Seamless MPLS		LDP Downstream-on-Demand in Seamless MPLS
	draft-ietf-mpls-ldp-dod-02		draft-ietf-mpls-ldp-dod-03
	Abstract		Abstract
	Seamless MPLS design enables a single IP/MPLS network to scale over		Seamless MPLS design enables a single IP/MPLS network to scale over
	core, metro and access parts of a large packet network infrastructure		core, metro and access parts of a large packet network infrastructure
	using standardized IP/MPLS protocols. One of the key goals of		using standardized IP/MPLS protocols. One of the key goals of
	Seamless MPLS is to meet requirements specific to access, including		Seamless MPLS is to meet requirements specific to access, including
	high number of devices, their position in network topology and their		high number of devices, their position in network topology and their
	compute and memory constraints that limit the amount of state access		compute and memory constraints that limit the amount of state access
	devices can hold.This can be achieved with LDP Downstream-on-Demand		devices can hold.This can be achieved with LDP Downstream-on-Demand
	skipping to change at page 2, line 8		skipping to change at page 2, line 8
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on January 16, 2013.		This Internet-Draft will expire on February 3, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 3, line 34		skipping to change at page 3, line 34
	4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 20		4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 20
	4.1. LDP Label Distribution Control and Retention Modes . . . . 20		4.1. LDP Label Distribution Control and Retention Modes . . . . 20
	4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 22		4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 22
	4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22		4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22
	4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 23		4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 23
	4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 23		4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 23
	4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 24		4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 24
	4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24		4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24
	4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26		4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26
	4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27		4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27
	4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27		4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 28
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28		5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 28		6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 28		6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 29
	6.1.1. Access to network packet flow direction . . . . . . . 28		6.1.1. Access to network packet flow direction . . . . . . . 29
	6.1.2. Network to access packet flow direction . . . . . . . 29		6.1.2. Network to access packet flow direction . . . . . . . 29
	6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30		6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30
	6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 31		6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 31
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 31		8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
	8.2. Informative References . . . . . . . . . . . . . . . . . . 32		8.2. Informative References . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single		Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single
	IP/MPLS network to scale over core, metro and access parts of a large		IP/MPLS network to scale over core, metro and access parts of a large
	packet network infrastructure using standardized IP/MPLS protocols.		packet network infrastructure using standardized IP/MPLS protocols.
	One of the key goals of Seamless MPLS is to meet requirements		One of the key goals of Seamless MPLS is to meet requirements
	specific to access, including high number of devices, their position		specific to access, including high number of devices, their position
	in network topology and their compute and memory constraints that		in network topology and their compute and memory constraints that
	limit the amount of state access devices can hold.		limit the amount of state access devices can hold.
	skipping to change at page 13, line 11		skipping to change at page 13, line 11
	traffic flows, AGN1x will be responding to access-originated LDP DoD		traffic flows, AGN1x will be responding to access-originated LDP DoD
	label requests with label mappings based on its BGP labeled unicast		label requests with label mappings based on its BGP labeled unicast
	reachability for requested FECs.		reachability for requested FECs.
	3.1.2. AN with Access IGP		3.1.2. AN with Access IGP
	If access IGP is used, AN(s) advertise their loopbacks over the		If access IGP is used, AN(s) advertise their loopbacks over the
	access IGP with configured metrics. AGN1x advertise a default route		access IGP with configured metrics. AGN1x advertise a default route
	over the access IGP.		over the access IGP.
	Similarly to the static route case, upstream AN/AGN1x should request
	labels over LDP DoD session(s) from downstream AN/AGN1x for all /32
	or /128 routes received over the access IGP.
	Routers request labels over LDP DoD session(s) according to their		Routers request labels over LDP DoD session(s) according to their
	needs for MPLS connectivity (LSPs). In particular if AGNs, as per		needs for MPLS connectivity (LSPs). In particular if AGNs, as per
	Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute		Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute
	routes from the IGP into BGP labeled unicast [RFC3107], they should		routes from the IGP into BGP labeled unicast [RFC3107], they should
	request labels over LDP DoD session(s) for those routes.		request labels over LDP DoD session(s) for those routes.
	Identically to the static route case, downstream AN/AGN1x should		Identically to the static route case, downstream AN/AGN1x should
	respond to the label request from the upstream AN/AGN1x with a label		respond to the label request from the upstream AN/AGN1x with a label
	mapping (if the requested route is present in its RIB, and there is a		mapping (if the requested route is present in its RIB, and there is a
	valid label binding from its downstream), and must install the		valid label binding from its downstream), and must install the
	skipping to change at page 21, line 19		skipping to change at page 21, line 15
	Using independent label distribution control with LDP DoD and access		Using independent label distribution control with LDP DoD and access
	static routing would prevent the access LSRs from propagating label		static routing would prevent the access LSRs from propagating label
	binding failure along the access topology, making it impossible for		binding failure along the access topology, making it impossible for
	upstream LSR to be notified about the downstream failure and for an		upstream LSR to be notified about the downstream failure and for an
	application using the LSP to switchover to an alternate path, even if		application using the LSP to switchover to an alternate path, even if
	such a path exists.		such a path exists.
	LDP protocol specification [RFC5036] defines two modes for label		LDP protocol specification [RFC5036] defines two modes for label
	retention, following the definitions in MPLS architecture [RFC3031]:		retention, following the definitions in MPLS architecture [RFC3031]:
	o Liberal mode - LSR retains every label mappings received from a		o Conservative mode - If operating in Downstream on Demand mode, an
	peer LSR, regardless of whether the peer LSR is the next-hop for		LSR will request label mappings only from the next hop LSR
	the advertised mapping. This mode allows for quicker adaptation		according to routing. The main advantage of the conservative mode
	to routing changes.		is that only the labels that are required for the forwarding of
			data are allocated and maintained. This is particularly important
			in LSRs where the label space is inherently limited, such as in an
			ATM switch. A disadvantage of the conservative mode is that if
			routing changes the next hop for a given destination, a new label
			must be obtained from the new next hop before labeled packets can
			be forwarded.
	o Conservative mode - LSR retains advertised label mappings only if		o Liberal mode - When operating in Downstream on Demand mode with
	they will be used to forward packets, that is only if they are		Liberal Label retention, an LSR might choose to request label
	received from a valid next-hop LSR according to routing. This		mappings for all known prefixes from all peer LSRs. The main
	mode allows LSR to maintain fewer labels, but slows down LSR		advantage of the Liberal Label retention mode is that reaction to
	adaptation to routing changes.		routing changes can be quick because labels already exist. The
			main disadvantage of the liberal mode is that unneeded label
			mappings are distributed and maintained.
	Due to the fact that according to LDP protocol specification		Note that the conservative label retention mode would prevent LSRs
	[RFC5036] conservative label retention mode calls for allocating and		from requesting and maintaining label mappings for any backup routes
	maintaining label mappings only if they are used for the forwarding		that are not used for forwarding. This in turn would prevent the
	of data, when used with LDP DoD the conservative label retention mode		access LSRs (AN and AGN1x nodes) from implementing any local
	would prevent LSRs operating in this mode to request and maintain		protection schemes that rely on using alternate next-hops in case of
	label mappings for any backup routes that are not used for		the primary next-hop failure. Such schemes include IPFRR LFA if
	forwarding. This in turn would prevent the access LSRs (AN and AGN1x		access IGP is used, or a primary and backup static route
	nodes) from implementing IPFRR LFA alternate based local-repair, as		configuration. Using LDP DoD in combination with liberal retention
	label mapping request can not be sent to alternate next-hops.		mode allows the LSR to request labels for the specific FEC from
			primary next-hop LSR(s) and the alternate next-hop LSR(s) for this
			FEC.
			Note that even though LDP DoD operates in a liberal retention mode,
			if used with access IGP and if no LFA exists, the LDP DoD will
			introduce additional delay in traffic restoration as the labels for
			the new next-hop will get requested only after the access IGP
			convergence.
	Adhering to the overall design goals of Seamless MPLS		Adhering to the overall design goals of Seamless MPLS
	[I-D.ietf-mpls-seamless-mpls], specifically achieving a large network		[I-D.ietf-mpls-seamless-mpls], specifically achieving a large network
	scale without compromising fast service restoration, all access LSRs		scale without compromising fast service restoration, all access LSRs
	(AN and AGN1x nodes) MUST use LDP DoD advertisement mode with:		(AN and AGN1x nodes) MUST use LDP DoD advertisement mode with:
	o Ordered label distribution control - enables propagation of label		o Ordered label distribution control - enables propagation of label
	binding failure within the access topology.		binding failure within the access topology.
	o Liberal label retention - enables pre-programming of alternate		o Liberal label retention - enables pre-programming of alternate
	next-hops with associated FEC labels.		next-hops with associated FEC labels.
	skipping to change at page 31, line 39		skipping to change at page 31, line 48
	o different crypto keys for use in authentication procedures for		o different crypto keys for use in authentication procedures for
	these locations.		these locations.
	o stricter network protection mechanisms including DoS protection,		o stricter network protection mechanisms including DoS protection,
	interface and session flap dampening.		interface and session flap dampening.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai		The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai
	Leymann and Ina Minei for their suggestions and review.		Leymann, Geraldine Calvignac and Ina Minei for their suggestions and
			review.
	8. References		8. References
	8.1. Normative References		8.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.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.		Specification", RFC 5036, October 2007.
End of changes. 14 change blocks.
	33 lines changed or deleted		47 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/