Diff: draft-ietf-mpls-mldp-hsmp-00.txt - draft-ietf-mpls-mldp-hsmp-01.txt

	draft-ietf-mpls-mldp-hsmp-00.txt	draft-ietf-mpls-mldp-hsmp-01.txt

	Network Working Group L. Jin	Network Working Group L. Jin

	Internet-Draft ZTE Corporation	Internet-Draft
	Intended status: Standards Track F. Jounay	Intended status: Standards Track F. Jounay

	Expires: March 24, 2013 France Telecom	Expires: October 20, 2013 France Telecom
	I. Wijnands	I. Wijnands
	Cisco Systems, Inc	Cisco Systems, Inc
	N. Leymann	N. Leymann
	Deutsche Telekom AG	Deutsche Telekom AG

	Sep 20, 2012	April 18, 2013

	LDP Extensions for Hub & Spoke Multipoint Label Switched Path	LDP Extensions for Hub & Spoke Multipoint Label Switched Path

	draft-ietf-mpls-mldp-hsmp-00.txt	draft-ietf-mpls-mldp-hsmp-01.txt

	Abstract	Abstract

	This draft introduces a hub & spoke multipoint LSP (short for HSMP	This draft introduces a hub & spoke multipoint LSP (short for HSMP
	LSP), which allows traffic both from root to leaf through P2MP LSP	LSP), which allows traffic both from root to leaf through P2MP LSP
	and also leaf to root along the co-routed reverse path. That means	and also leaf to root along the co-routed reverse path. That means
	traffic entering the HSMP LSP from application/customer at the root	traffic entering the HSMP LSP from application/customer at the root
	node travels downstream, exactly as if it was traveling downstream	node travels downstream, exactly as if it was traveling downstream
	along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP	along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP
	at any leaf node travels upstream along the tree to the root as if it	at any leaf node travels upstream along the tree to the root as if it

	skipping to change at page 1, line 49	skipping to change at page 1, line 49
	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 March 24, 2013.	This Internet-Draft will expire on October 20, 2013.

	Copyright Notice	Copyright Notice


	Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must	to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of	include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as	the Trust Legal Provisions and are provided without warranty as

	skipping to change at page 2, line 38	skipping to change at page 2, line 38
	4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 5	4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 5
	4.1. Support for HSMP LSP setup with LDP . . . . . . . . . . . 5	4.1. Support for HSMP LSP setup with LDP . . . . . . . . . . . 5
	4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 6	4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 6
	4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6	4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6
	4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 6	4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 6
	4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 8	4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 8
	4.3.3. HSMP LSP upstream LSR change . . . . . . . . . . . . . 9	4.3.3. HSMP LSP upstream LSR change . . . . . . . . . . . . . 9
	5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 9	5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 9
	6. Redundancy considerations . . . . . . . . . . . . . . . . . . 9	6. Redundancy considerations . . . . . . . . . . . . . . . . . . 9
	7. Co-routed path exceptions . . . . . . . . . . . . . . . . . . 9	7. Co-routed path exceptions . . . . . . . . . . . . . . . . . . 9

	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10	8. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10	9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10	11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
	11.1. Normative references . . . . . . . . . . . . . . . . . . . 10	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	11.2. Informative References . . . . . . . . . . . . . . . . . . 11	12.1. Normative references . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11	12.2. Informative References . . . . . . . . . . . . . . . . . . 12
		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

	1. Introduction	1. Introduction

	The point-to-multipoint LSP defined in [RFC6388] allows traffic to	The point-to-multipoint LSP defined in [RFC6388] allows traffic to
	transmit from root to several leaf nodes, and multipoint-to-	transmit from root to several leaf nodes, and multipoint-to-
	multipoint LSP allows traffic from every node to transmit to every	multipoint LSP allows traffic from every node to transmit to every
	other node. This draft introduces a hub & spoke multipoint LSP	other node. This draft introduces a hub & spoke multipoint LSP
	(short for HSMP LSP), which allows traffic both from root to leaf	(short for HSMP LSP), which allows traffic both from root to leaf
	through P2MP LSP and also leaf to root along the co-routed reverse	through P2MP LSP and also leaf to root along the co-routed reverse
	path. That means traffic entering the HSMP LSP at the root node	path. That means traffic entering the HSMP LSP at the root node

	skipping to change at page 10, line 5	skipping to change at page 10, line 5
	7. Co-routed path exceptions	7. Co-routed path exceptions

	There are some exceptional cases that mLDP based HSMP LSP could not	There are some exceptional cases that mLDP based HSMP LSP could not
	achieve co-routed path. One possible case is using static routing	achieve co-routed path. One possible case is using static routing
	between LDP neighbors; another possible case is IGP cost asymmetric	between LDP neighbors; another possible case is IGP cost asymmetric
	generated by physical link cost asymmetric, or TE-Tunnels used	generated by physical link cost asymmetric, or TE-Tunnels used
	between LDP neighbors. The LSR/LER in HSMP LSP could detect if the	between LDP neighbors. The LSR/LER in HSMP LSP could detect if the
	path is co-routed or not, if not co-routed, an indication could be	path is co-routed or not, if not co-routed, an indication could be
	generated to the management system.	generated to the management system.


	8. Security Considerations	8. Failure Detection of HSMP LSP

		The idea of LSP ping for HSMP LSPs could be expressed as an intention
		to test the packets that enter at the root along a particular
		downstream path of HSMP LSP, and end their MPLS path on the leaf.
		The leaf node then sends the LSP ping response along the co-routed
		upstream path of HSMP LSP, and end on the root that are the
		(intended) root node.

		New sub-TLVs are required to be assigned by IANA in Target FEC Stack
		TLV to define the corresponding HSMP-upstream FEC type and HSMP-
		downstream FEC type. In order to ensure the leaf node to send the
		LSP ping response along the HSMP upstream path, the R bit (Validate
		Reverse Path) in Global Flags Field defined in [RFC6426] is reused
		here.

		The node processing mechanism of LSP ping for HSMP LSP is inherited
		from [RFC6425] and [RFC6426] section 3.4, except the following:

		1. The root node sending LSP ping message for HSMP LSP MUST attach
		Target FEC Stack with HSMP downstream FEC, and set R bit to '1' in
		Global Flags Field.

		2. When the leaf node receiving the LSP ping, it MUST send the LSP
		ping response to the associated HSMP upstream path. The Reverse-path
		Target FEC Stack TLV attached by leaf node in reply message SHOULD
		contain the sub-TLV of associated HSMP upstream FEC.

		9. Security Considerations

	The same security considerations apply as for the MP2MP LSP described	The same security considerations apply as for the MP2MP LSP described

	in [RFC6388].	in [RFC6388] and [RFC6425].


	9. IANA Considerations	10. IANA Considerations

	This document requires allocation of two new LDP FEC Element types	This document requires allocation of two new LDP FEC Element types
	from the "Label Distribution Protocol (LDP) Parameters registry" the	from the "Label Distribution Protocol (LDP) Parameters registry" the
	"Forwarding Equivalence Class (FEC) Type Name Space":	"Forwarding Equivalence Class (FEC) Type Name Space":

	1. the HSMP-upstream FEC type - requested value TBD	1. the HSMP-upstream FEC type - requested value TBD

	2. the HSMP-downstream FEC type - requested value TBD	2. the HSMP-downstream FEC type - requested value TBD

	This document requires allocation of one new code points for the HSMP	This document requires allocation of one new code points for the HSMP
	LSP capability TLV from "Label Distribution Protocol (LDP) Parameters	LSP capability TLV from "Label Distribution Protocol (LDP) Parameters
	registry" the "TLV Type Name Space":	registry" the "TLV Type Name Space":

	HSMP LSP Capability Parameter - requested value TBD	HSMP LSP Capability Parameter - requested value TBD


	10. Acknowledgement	This document requires allocation of two new sub-TLV types for
		inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV
		type 1).

		1. the HSMP-upstream LDP FEC Stack - requested value TBD

		2. the HSMP-downstream LDP FEC Stack - requested value TBD

		11. Acknowledgement

	The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su,	The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su,
	Edward, Mach Chen, Thomas Morin for their valuable comments.	Edward, Mach Chen, Thomas Morin for their valuable comments.


	11. References	12. References


	11.1. Normative references	12.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.

	[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS	[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
	Multicast Encapsulations", RFC 5332, August 2008.	Multicast Encapsulations", RFC 5332, August 2008.

	[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.	[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
	Le Roux, "LDP Capabilities", RFC 5561, July 2009.	Le Roux, "LDP Capabilities", RFC 5561, July 2009.

	[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,	[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
	"Label Distribution Protocol Extensions for Point-to-	"Label Distribution Protocol Extensions for Point-to-
	Multipoint and Multipoint-to-Multipoint Label Switched	Multipoint and Multipoint-to-Multipoint Label Switched
	Paths", RFC 6388, November 2011.	Paths", RFC 6388, November 2011.

	[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label	[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
	Assignment for LDP", RFC 6389, November 2011.	Assignment for LDP", RFC 6389, November 2011.


	11.2. Informative References	[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa,
		S., and T. Nadeau, "Detecting Data-Plane Failures in
		Point-to-Multipoint MPLS - Extensions to LSP Ping",
		RFC 6425, November 2011.

		[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
		On-Demand Connectivity Verification and Route Tracing",
		RFC 6426, November 2011.

		12.2. Informative References

	[I-D.ietf-l2vpn-vpms-frmwk-requirements]	[I-D.ietf-l2vpn-vpms-frmwk-requirements]
	Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,	Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
	and L. Jin, "Framework and Requirements for Virtual	and L. Jin, "Framework and Requirements for Virtual
	Private Multicast Service (VPMS)",	Private Multicast Service (VPMS)",

	draft-ietf-l2vpn-vpms-frmwk-requirements-04 (work in	draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in
	progress), July 2011.	progress), October 2012.

	[I-D.ietf-pwe3-p2mp-pw]	[I-D.ietf-pwe3-p2mp-pw]
	Sivabalan, S., Boutros, S., and L. Martini, "Signaling	Sivabalan, S., Boutros, S., and L. Martini, "Signaling
	Root-Initiated Point-to-Multipoint Pseudowire using LDP",	Root-Initiated Point-to-Multipoint Pseudowire using LDP",
	draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012.	draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012.

	[I-D.ietf-tictoc-1588overmpls]	[I-D.ietf-tictoc-1588overmpls]
	Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.	Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.

	Montini, "Transporting PTP messages (1588) over MPLS	Montini, "Transporting Timing messages over MPLS
	Networks", draft-ietf-tictoc-1588overmpls-02 (work in	Networks", draft-ietf-tictoc-1588overmpls-04 (work in
	progress), October 2011.	progress), February 2013.

	[IEEE1588]	[IEEE1588]
	"IEEE standard for a precision clock synchronization	"IEEE standard for a precision clock synchronization
	protocol for networked measurement and control systems",	protocol for networked measurement and control systems",
	IEEE1588v2 , March 2008.	IEEE1588v2 , March 2008.


		[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
		Label Switched (MPLS) Data Plane Failures", RFC 4379,
		February 2006.

	[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service	[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
	(VPLS) Using Label Distribution Protocol (LDP) Signaling",	(VPLS) Using Label Distribution Protocol (LDP) Signaling",
	RFC 4762, January 2007.	RFC 4762, January 2007.

	[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay	[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
	Measurement for MPLS Networks", RFC 6374, September 2011.	Measurement for MPLS Networks", RFC 6374, September 2011.

	Authors' Addresses	Authors' Addresses

	Lizhong Jin	Lizhong Jin

	ZTE Corporation	Shanghai, China
	889, Bibo Road
	Shanghai, 201203, China


	Email: lizhong.jin@zte.com.cn	Email: lizho.jin@gmail.com
	Frederic Jounay	Frederic Jounay
	France Telecom	France Telecom
	2, avenue Pierre-Marzin	2, avenue Pierre-Marzin
	22307 Lannion Cedex, FRANCE	22307 Lannion Cedex, FRANCE

	Email: frederic.jounay@orange.ch	Email: frederic.jounay@orange.ch

	IJsbrand Wijnands	IJsbrand Wijnands
	Cisco Systems, Inc	Cisco Systems, Inc
	De kleetlaan 6a	De kleetlaan 6a

End of changes. 19 change blocks.
	29 lines changed or deleted	77 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/