< draft-ietf-mpls-p2mp-te-bypass-01.txt		draft-ietf-mpls-p2mp-te-bypass-02.txt >
	Network Working Group J.L. Le Roux (Ed.)		Network Working Group J.L. Le Roux (Ed.)
	Internet Draft France Telecom		Internet Draft France Telecom
	Category: Standard Track		Category: Standard Track
	Expires: January 2008 R. Aggarwal		Expires: August 2008 R. Aggarwal
	Juniper Networks		Juniper Networks
	J.P. Vasseur		J.P. Vasseur
	Cisco Systems, Inc.		Cisco Systems, Inc.
	M. Vigoureux		M. Vigoureux
	Alcatel-Lucent		Alcatel-Lucent
	July 2007		March 2008
	P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels		P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels
	draft-ietf-mpls-p2mp-te-bypass-01.txt		draft-ietf-mpls-p2mp-te-bypass-02.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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	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."
	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.
	Abstract		Abstract
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 38 ¶
	LSPs of a given backup P2MP LSP, tunneled within the same P2MP Bypass		LSPs of a given backup P2MP LSP, tunneled within the same P2MP Bypass
	Tunnel. This backup label will indicate to the Merge Points that		Tunnel. This backup label will indicate to the Merge Points that
	packets received with that label should be switched along the		packets received with that label should be switched along the
	protected P2MP LSP.		protected P2MP LSP.
	For that purpose upstream label assignment procedures defined in		For that purpose upstream label assignment procedures defined in
	[MPLS-UPSTREAM] and RSVP-TE extensions for upstream label assignment		[MPLS-UPSTREAM] and RSVP-TE extensions for upstream label assignment
	defined in [RSVP-UP] MUST be used. To signal a backup P2MP LSP, the		defined in [RSVP-UP] MUST be used. To signal a backup P2MP LSP, the
	same backup label, is distributed by the PLR to all MPs belonging to		same backup label, is distributed by the PLR to all MPs belonging to
	a same P2MP Bypass Tunnel, in the context of this P2MP Bypass Tunnel.		a same P2MP Bypass Tunnel, in the context of this P2MP Bypass Tunnel.
	This requires the backup P2MP LSP to be signaled prior to the failure.		This requires the backup P2MP LSP to be signaled prior to the failure
	At the MP, backup S2L sub-LSPs (i.e., S2L sub-LSPs of the Backup P2MP		At the MP, backup S2L sub-LSPs (i.e., S2L sub-LSPs of the Backup P2MP
	LSP) are merged with protected S2L sub-LSPs. A MP (i.e., the bypass		LSP) are merged with protected S2L sub-LSPs. A MP (i.e., the bypass
	tunnel leaf LSRs), maintains a context specific Incoming Label Map		tunnel leaf LSRs), maintains a context specific Incoming Label Map
	(ILM) for the P2MP Bypass Tunnel. This can be implemented by		(ILM) for the P2MP Bypass Tunnel. This can be implemented by
	maintaining a different context specific ILM for each LSR that is the		maintaining a different context specific ILM for each LSR that is the
	root of a P2MP Bypass Tunnel (per-neighbor), or by maintaining a		root of a P2MP Bypass Tunnel (per-neighbor), or by maintaining a
	different context specific ILM for each P2MP Bypass Tunnel (per-		different context specific ILM for each P2MP Bypass Tunnel (per-
	tunnel). The context of an inner label (i.e., a backup label) is		tunnel). The context of an inner label (i.e., a backup label) is
	determined by the underlying P2MP Bypass Tunnel on which it is		determined by the underlying P2MP Bypass Tunnel on which it is
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	{LSR1.LSRn} may be a superset of {MP1.MPq}, that is some leaf LSRs of		{LSR1.LSRn} may be a superset of {MP1.MPq}, that is some leaf LSRs of
	a given P2MP Bypass Tunnel, noted {LSRx.LSRy}, may not belong to		a given P2MP Bypass Tunnel, noted {LSRx.LSRy}, may not belong to
	{MP1.MPq}. The PLR will not distribute the backup label for the		{MP1.MPq}. The PLR will not distribute the backup label for the
	backup P2MP LSP to these LSRs {LSRx.LSRy}.		backup P2MP LSP to these LSRs {LSRx.LSRy}.
	However due to the nature of the P2MP Bypass Tunnel, during failure,		However due to the nature of the P2MP Bypass Tunnel, during failure,
	packets with the backup label will also be delivered onto the P2MP		packets with the backup label will also be delivered onto the P2MP
	Bypass Tunnel to {LSRx.LSRy}. {LSRx.LSRy} MUST discard these packets		Bypass Tunnel to {LSRx.LSRy}. {LSRx.LSRy} MUST discard these packets
	based on the absence of an entry for this label in the context		based on the absence of an entry for this label in the context
	specific ILM referred to that P2MP Bypass Tunnel. This requires that		specific ILM referred to that P2MP Bypass Tunnel. This requires that
	{LSRx.LSRy} create a context specific ILM (per-tunnel or per-neighbor)		{LSRx.LSRy} create a context specific ILM, per-tunnel or per-neighbor
	for that P2MP Bypass Tunnel label.		for that P2MP Bypass Tunnel label.
	PHP MUST be deactivated on the P2MP Bypass Tunnel, in order to allow		PHP MUST be deactivated on the P2MP Bypass Tunnel, in order to allow
	MPs to determine the context for the backup labels assigned by the		MPs to determine the context for the backup labels assigned by the
	PLR. Hence the P2MP Bypass Tunnel will be signaled with the "non PHP		PLR. Hence the P2MP Bypass Tunnel will be signaled with the "non PHP
	behavior desired" bit set in the Attribute Flags TLV as specified in		behavior desired" bit set in the Attribute Flags TLV as specified in
	[NO-PHP].		[NO-PHP].
	Note that P2MP Bypass Tunnels may be signaled in advance, prior to		Note that P2MP Bypass Tunnels may be signaled in advance, prior to
	the establishment of any protected P2MP LSP, either automatically or		the establishment of any protected P2MP LSP, either automatically or
	skipping to change at page 9, line 31 ¶		skipping to change at page 9, line 31 ¶
	object, or both.		object, or both.
	A MP MUST maintain one context specific ILM table per PLR or per P2MP		A MP MUST maintain one context specific ILM table per PLR or per P2MP
	Bypass Tunnel for which it is a leaf LSR.		Bypass Tunnel for which it is a leaf LSR.
	A MP MUST install the upstream assigned label received in a backup		A MP MUST install the upstream assigned label received in a backup
	LSP's Path message (i.e., the backup label), within an ILM either		LSP's Path message (i.e., the backup label), within an ILM either
	specific to the underlying P2MP Bypass Tunnel or specific to the PLR,		specific to the underlying P2MP Bypass Tunnel or specific to the PLR,
	which is the ingress node of the underlying P2MP Bypass Tunnel. The		which is the ingress node of the underlying P2MP Bypass Tunnel. The
	underlying P2MP bypass tunnel is identified by its session object,		underlying P2MP bypass tunnel is identified by its session object,
	carried within the IF_ID_RSVP_HOP object of the backup LSP’s Path		carried within the IF_ID_RSVP_HOP object of the backup LSP's Path
	message. An upstream assigned label for a backup P2MP LSP MUST be		message. An upstream assigned label for a backup P2MP LSP MUST be
	mapped to the outgoing interface(s) and label(s) of the corresponding		mapped to the outgoing interface(s) and label(s) of the corresponding
	protected P2MP LSP.		protected P2MP LSP.
	As specified in [RSVP-UP], the Resv message sent by a MP to the PLR,		As specified in [RSVP-UP], the Resv message sent by a MP to the PLR,
	does not carry any Label Object.		does not carry any Label Object.
	The processing of backup S2L sub-LSP SEROs/SRROs MUST follow		The processing of backup S2L sub-LSP SEROs/SRROs MUST follow
	backup tunnel ERO/RRO processing described in [RFC4090].		backup tunnel ERO/RRO processing described in [RFC4090].
	skipping to change at page 11, line 40 ¶		skipping to change at page 11, line 40 ¶
	Bit Number: 8 (suggested value)		Bit Number: 8 (suggested value)
	Meaning: P2MP Partial Protection Desired		Meaning: P2MP Partial Protection Desired
	Used in Attributes Flags on Path: Yes		Used in Attributes Flags on Path: Yes
	Used in Attributes Flags on Resv: No		Used in Attributes Flags on Resv: No
	Used in Attributes Flags on RRO: Yes		Used in Attributes Flags on RRO: Yes
	Referenced Section of this Doc: 7		Referenced Section of this Doc: 7
	11. Acknowledgments		11. Acknowledgments
	We would like to thank Kireeti Kompella, Venu Hemige, Laurent		We would like to thank Kireeti Kompella, Venu Hemige, Laurent
	Ciavaglia, Yannick Bréhon, and Mohamad Chaitou, for the useful		Ciavaglia, and Yannick Brehon, for the useful comments and
	comments and discussions.		discussions.
	12. References		12. References
	12.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.
	[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture",		[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture",
	RFC 3031.		RFC 3031.
	skipping to change at page 12, line 34 ¶		skipping to change at page 12, line 34 ¶
	RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress.		RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress.
	[RFC4420] Farrel, A., Ed., et al."Encoding of Attributes for		[RFC4420] Farrel, A., Ed., et al."Encoding of Attributes for
	Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)		Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
	Establishment Using Resource ReserVation Protocol-Traffic Engineering		Establishment Using Resource ReserVation Protocol-Traffic Engineering
	(RSVP-TE)", RFC 4420, February 2006.		(RSVP-TE)", RFC 4420, February 2006.
	12.2. Informational references		12.2. Informational references
	[NO-PHP] Ali, Swallow, Aggarwal, "Non PHP Behavior and out-of-band		[NO-PHP] Ali, Swallow, Aggarwal, "Non PHP Behavior and out-of-band
	mapping for RSVP-TE LSPs", draft-ali-mpls-rsvp-te-no-php-oob-mapping,		mapping for RSVP-TE LSPs", draft-ietf-mpls-rsvp-te-no-php-oob-
	work in progress		mapping, work in progress
	13. Authors' Addresses:		13. Authors' Addresses:
	Jean-Louis Le Roux		Jean-Louis Le Roux
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
	FRANCE		FRANCE
	Email: jeanlouis.leroux@orange-ftgroup.com		Email: jeanlouis.leroux@orange-ftgroup.com
	skipping to change at page 13, line 18 ¶		skipping to change at page 13, line 18 ¶
	USA		USA
	Email: jpv@cisco.com		Email: jpv@cisco.com
	M. Vigoureux		M. Vigoureux
	Alcatel-Lucent France		Alcatel-Lucent France
	Route de Villejust		Route de Villejust
	91620 Nozay		91620 Nozay
	FRANCE		FRANCE
	Email: martin.vigoureux@alcatel-lucent.fr		Email: martin.vigoureux@alcatel-lucent.fr
	14. Intellectual Property Statement		14. Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 4 ¶
	This document and the information contained herein are provided		This document and the information contained herein are provided
	on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE		WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.		FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The IETF Trust (2007). This document is subject to the		Copyright (C) The IETF Trust (2008). This document is subject to the
	rights, licenses and restrictions contained in BCP 78, and except as		rights, licenses and restrictions contained in BCP 78, and except as
	set forth therein, the authors retain all their rights.		set forth therein, the authors retain all their rights.
End of changes. 11 change blocks.
	13 lines changed or deleted		13 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/