draft-ietf-mpls-ldp-dod-06.txt		draft-ietf-mpls-ldp-dod-07.txt
	Network Working Group T. Beckhaus		Network Working Group T. Beckhaus
	Internet-Draft Deutsche Telekom AG		Internet-Draft Deutsche Telekom AG
	Intended status: Standards Track B. Decraene		Intended status: Standards Track B. Decraene
	Expires: November 11, 2013 France Telecom		Expires: November 14, 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.
	May 10, 2013		May 13, 2013
	LDP Downstream-on-Demand in Seamless MPLS		LDP Downstream-on-Demand in Seamless MPLS
	draft-ietf-mpls-ldp-dod-06		draft-ietf-mpls-ldp-dod-07
	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 10		skipping to change at page 2, line 10
	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 November 11, 2013.		This Internet-Draft will expire on November 14, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 26, line 38		skipping to change at page 26, line 38
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|0| Queue Request (0x0971) | Length (0x00) |		|1|0| Queue Request (0x0971) | Length (0x00) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	U-bit = 1		U-bit = 1
	Unknown TLV bit. Upon receipt of an unknown TLV, due to U-bit		Unknown TLV bit. Upon receipt of an unknown TLV, due to U-bit
	being set (=1), the unknown TLV MUST be silently ignored and the		being set (=1), the unknown TLV MUST be silently ignored and the
	rest of the message processed as if the unknown TLV did not exist.		rest of the message processed as if the unknown TLV did not
	In case requested route is not available, the downstream LSR MUST		exist. In case requested route is not available, the downstream
	ignore this unknown TLV and send a "no route" notification back.		LSR MUST ignore this unknown TLV and send a "no route"
	Ensures backward compatibility.		notification back. Ensures backward compatibility.
	F-bit = 0		F-bit = 0
	Forward unknown TLV bit. This bit applies only when the U-bit is		Forward unknown TLV bit. This bit applies only when the U-bit is
	set and the LDP message containing the unknown TLV is to be		set and the LDP message containing the unknown TLV is to be
	forwarded. Due to F-bit being clear (=0), the unknown TLV is not		forwarded. Due to F-bit being clear (=0), the unknown TLV is not
	forwarded with the containing message.		forwarded with the containing message.
	Type		Type
	Queue Request Type value to be allocated by IANA.		Queue Request Type value to be allocated by IANA.
	skipping to change at page 31, line 37		skipping to change at page 31, line 37
	attacker to get those keys easily. Software tools should monitor and		attacker to get those keys easily. Software tools should monitor and
	keep checking the integrity of the Access Node configuration and		keep checking the integrity of the Access Node configuration and
	software version. Note that this is not specific to the node using		software version. Note that this is not specific to the node using
	LDP DoD. In the contrary, the use of LDP DoD will allow the upstream		LDP DoD. In the contrary, the use of LDP DoD will allow the upstream
	/network to check, log and possibly deny the FEC requests from the		/network to check, log and possibly deny the FEC requests from the
	Access Node.		Access Node.
	8. Acknowledgements		8. Acknowledgements
	The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai		The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai
	Leymann, Geraldine Calvignac, Ina Minei, Eric Gray and Lizhong Jin		Leymann, George Swallow, Geraldine Calvignac, Ina Minei, Eric Gray
	for their suggestions and review.		and Lizhong Jin for their suggestions and review. Additional thanks
			go to Adrian Farrel for thorough pre-publication review and editing
			suggestions.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-mpls-seamless-mpls]
	Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
	M., and D. Steinberg, "Seamless MPLS Architecture", draft-
	ietf-mpls-seamless-mpls-02 (work in progress), October
	2012.
	[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.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031, January 2001.		Label Switching Architecture", RFC 3031, January 2001.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, February 2006.		Networks (VPNs)", RFC 4364, February 2006.
	[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.		[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
	Heron, "Pseudowire Setup and Maintenance Using the Label		Heron, "Pseudowire Setup and Maintenance Using the Label
	Distribution Protocol (LDP)", RFC 4447, April 2006.		Distribution Protocol (LDP)", RFC 4447, April 2006.
	[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.
	[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension		[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
	for Inter-Area Label Switched Paths (LSPs)", RFC 5283,		for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
	July 2008.		July 2008.
	[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
	Networks", RFC 5920, July 2010.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-karp-routing-tcp-analysis]		[I-D.ietf-karp-routing-tcp-analysis]
	Jethanandani, M., Patel, K., and L. Zheng, "Analysis of		Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
	BGP, LDP, PCEP and MSDP Issues According to KARP Design		BGP, LDP, PCEP and MSDP Issues According to KARP Design
	Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in		Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
	progress), April 2013.		progress), April 2013.
			[I-D.ietf-mpls-seamless-mpls]
			Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
			M., and D. Steinberg, "Seamless MPLS Architecture", draft-
			ietf-mpls-seamless-mpls-02 (work in progress), October
			2012.
	[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in		[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
	BGP-4", RFC 3107, May 2001.		BGP-4", RFC 3107, May 2001.
	[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP		[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
	Synchronization", RFC 5443, March 2009.		Synchronization", RFC 5443, March 2009.
			[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
			Networks", RFC 5920, July 2010.
	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP		[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, June 2010.		Authentication Option", RFC 5925, June 2010.
	[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security		[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
	According to the Keying and Authentication for Routing		According to the Keying and Authentication for Routing
	Protocols (KARP) Design Guide", RFC 6863, March 2013.		Protocols (KARP) Design Guide", RFC 6863, March 2013.
	Authors' Addresses		Authors' Addresses
	Thomas Beckhaus		Thomas Beckhaus
	Deutsche Telekom AG		Deutsche Telekom AG
End of changes. 10 change blocks.
	19 lines changed or deleted		21 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/