Subject: [PWE3] A question regarding torn down PWs in draft-ietf-pwe3-oam-msg-map-08.txt

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 5 Jan 2009 12:11:41 +0200

Hi Monique/Mustapha/Peter/Dave/Thom/Luca,
I have a question to you as the editors of the expired) draft-ietf-pwe3-oam-msg-map-08.txt.
The question is related to the following text in Section 8.2.1. PW Forward Defect State Entry/Exit Criteria:
<quote>
   Note that if the PW control session between the PEs fails, the PW is
   torn down and needs to be re-established. This includes failure of
   the T-LDP session, the L2TP session, or the L2TP control connection.
   However, the consequent actions towards the ACs are the same as if
   the PW entered the forward defect state.
<end quote>
The PW may be torn down not just because the PW control session between the PEs fails. E.g., the PW can be deleted by the operator in one of the PEs.
Does the quoted text imply that implementations must distinguish between PWs being torn down due to failures of their control sessions and PWs that are torn down for any other reason?
The use case of special interest would be a PW that has been set up (and later torn down) using a single-sided mechanism...
I'd also like to note that there are several references in the draft to unspecified defects  "that do not result in the PW being torn down"...

Regards,
     Sasha

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Mon, 5 Jan 2009 07:51:28 -0600

Hi Sasha,
 
>> Does the quoted text imply that implementations must distinguish
between PWs being torn down
>> due to failures of their control sessions and PWs that are torn down
for any other reason?
 
Whether PWs are torn down because of a defect (whether it is in the
control plane or in the data plane), the consequent actions are the
same. It would be good, however, if a PE would be able to distinguish
between PWs torn down because of defects and PWs torn down for
administrative reasons, because in the latter case there is no need to
insert an FDI message downstream.
 
Remember that Luca sent an email to the list proposing to add a BFD code
point to indicate that an AC was taken down for admistrative reasons.
That proposal was driven by the same motivation.
 
Peter

________________________________

	From: Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: Monday, January 05, 2009 5:12 AM
	To: Aissaoui, Mustapha (Mustapha); Busschbach, Peter B (Peter);
[email-masked]; [email-masked]; Thomas D. Nadeau;
[email-masked]
	Cc: [email-masked]; Shell Nakash; Prashant Desai; Igor
Danilovich; Itamar Levy
	Subject: A question regarding torn down PWs in
draft-ietf-pwe3-oam-msg-map-08.txt

	Hi Monique/Mustapha/Peter/Dave/Thom/Luca,
	I have a question to you as the editors of the expired)
draft-ietf-pwe3-oam-msg-map-08.txt.
	The question is related to the following text in Section 8.2.1.
PW Forward Defect State Entry/Exit Criteria:
	<quote>

		   Note that if the PW control session between the PEs
fails, the PW is 
		   torn down and needs to be re-established. This
includes failure of 
		   the T-LDP session, the L2TP session, or the L2TP
control connection. 
		   However, the consequent actions towards the ACs are
the same as if 
		   the PW entered the forward defect state.

	<end quote>
	The PW may be torn down not just because the PW control session
between the PEs fails. E.g., the PW can be deleted by the operator in
one of the PEs.
	Does the quoted text imply that implementations must distinguish
between PWs being torn down due to failures of their control sessions
and PWs that are torn down for any other reason?
	The use case of special interest would be a PW that has been set
up (and later torn down) using a single-sided mechanism...
	I'd also like to note that there are several references in the
draft to unspecified defects  "that do not result in the PW being torn
down"...
	 
	Regards,
	     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 5 Jan 2009 17:08:58 +0200

Peter hi,
Lots of thanks for a prompt response.

Please see some comments inline below (blue italics).

Regards,
    Sasha

________________________________
From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
Sent: Monday, January 05, 2009 3:51 PM
To: Alexander Vainshtein; Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]; Thomas D. Nadeau; [email-masked]
Cc: [email-masked]; Shell Nakash; Prashant Desai; Igor Danilovich; Itamar Levy
Subject: RE: A question regarding torn down PWs in draft-ietf-pwe3-oam-msg-map-08.txt

Hi Sasha,

>> Does the quoted text imply that implementations must distinguish between PWs being torn down
>> due to failures of their control sessions and PWs that are torn down for any other reason?

Whether PWs are torn down because of a defect (whether it is in the control plane or in the data plane), the consequent actions are the same.
[[Sasha]] I am not aware of the case when a PW is torn down due to defects in the data plane. Could you please provide a reference/an example?
 It would be good, however, if a PE would be able to distinguish between PWs torn down because of defects and PWs torn down for administrative reasons, because in the latter case there is no need to insert an FDI message downstream.
[[Sasha]] I do not think that RFC 4447 provides for that. In addition, please consider the following scenario:

 1.  A PW is set up
 2.  The PW is torn down due to the CP defect (targeted LDP session went down). FDI is inserted in the local AC
 3.   The user has deleted the PW end point in the remote PE. Since the LDP session is down, this fact is not communicated to the local PE
 4.  Targeted LDP session is restored but an attempt of the local PE to restore the PW fails since there is no remote peer anymore. What should now happen to the local AC?

Remember that Luca sent an email to the list proposing to add a BFD code point to indicate that an AC was taken down for admistrative reasons. That proposal was driven by the same motivation.
[[Sasha]] I remember that, and I believe I've sent a couple of messages to the list questioning the rationale of such a code point.

Peter

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, January 05, 2009 5:12 AM
To: Aissaoui, Mustapha (Mustapha); Busschbach, Peter B (Peter); [email-masked]; [email-masked]; Thomas D. Nadeau; [email-masked]
Cc: [email-masked]; Shell Nakash; Prashant Desai; Igor Danilovich; Itamar Levy
Subject: A question regarding torn down PWs in draft-ietf-pwe3-oam-msg-map-08.txt

Regards,
     Sasha

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Mon, 5 Jan 2009 10:12:43 -0600

Sasha,
 
Please see in-line

	From: Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: Monday, January 05, 2009 10:09 AM
	
	[snipped] 

		[[Sasha]] I am not aware of the case when a PW is torn
down due to defects in the data plane. Could you please provide a
reference/an example?

		[PB]  See section 5.4.1 of RFC 4447: a simple label
withdraw method MAY also be
		   supported as a legacy means of signaling PW status
and AC status

		 It would be good, however, if a PE would be able to
distinguish between PWs torn down because of defects and PWs torn down
for administrative reasons, because in the latter case there is no need
to insert an FDI message downstream.
		[[Sasha]] I do not think that RFC 4447 provides for
that. In addition, please consider the following scenario:

		1.	A PW is set up 
		2.	The PW is torn down due to the CP defect
(targeted LDP session went down). FDI is inserted in the local AC 
		3.	 The user has deleted the PW end point in the
remote PE. Since the LDP session is down, this fact is not communicated
to the local PE 
		4.	Targeted LDP session is restored but an attempt
of the local PE to restore the PW fails since there is no remote peer
anymore. What should now happen to the local AC

		[PB] I don't understand the example. Who is the user
that removes the PW end point? A service provider? If so, why would that
service provider update one PE to remove the PW but not the peer? 
		 
		In any case, if the local PE is inserting FDI messages
periodically on the local AC, it will continue doing so as long as the
PW is not restored. Do you believe it should behave otherwise?
		 
		[snipped to the end]

---

From: "David Allan" <[email-masked]>
Date: Mon, 5 Jan 2009 11:15:53 -0500

hi Peter:
 
Below you suggest that FDI not be inserted when a PW is taken down
administratively. I do not understand why this is different from any
other disruption of connectivity, unless it is beleived that an
administrative action is joined up across both MPLS PWs and the native
service by other means....
 
Am I missing somthing?
 
cheers
Dave

 

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, January 05, 2009 10:09 AM
To: Busschbach, Peter B (Peter)
Cc: [email-masked]; Shell Nakash; Prashant Desai; Igor Danilovich; Itamar
Levy; Aissaoui, Mustapha (Mustapha); Allan, David (CAR:NS00);
[email-masked]; Thomas D. Nadeau; [email-masked]
Subject: RE: A question regarding torn down PWs in
draft-ietf-pwe3-oam-msg-map-08.txt

Peter hi,

Regards,
    Sasha

	From: Busschbach, Peter B (Peter)
[mailto:[email-masked]] 
	Sent: Monday, January 05, 2009 3:51 PM
	To: Alexander Vainshtein; Aissaoui, Mustapha (Mustapha);
[email-masked]; [email-masked]; Thomas D. Nadeau;
[email-masked]
	Cc: [email-masked]; Shell Nakash; Prashant Desai; Igor
Danilovich; Itamar Levy
	Subject: RE: A question regarding torn down PWs in
draft-ietf-pwe3-oam-msg-map-08.txt

	Hi Sasha,
	 
	>> due to failures of their control sessions and PWs that are
torn down for any other reason?
	 
	Whether PWs are torn down because of a defect (whether it is in
the control plane or in the data plane), the consequent actions are the
same.
	[[Sasha]] I am not aware of the case when a PW is torn down due
to defects in the data plane. Could you please provide a reference/an
example?
	 It would be good, however, if a PE would be able to distinguish
between PWs torn down because of defects and PWs torn down for
administrative reasons, because in the latter case there is no need to
insert an FDI message downstream.
	[[Sasha]] I do not think that RFC 4447 provides for that. In
addition, please consider the following scenario:

	1.	A PW is set up 
	2.	The PW is torn down due to the CP defect (targeted LDP
session went down). FDI is inserted in the local AC 
	3.	 The user has deleted the PW end point in the remote PE.
Since the LDP session is down, this fact is not communicated to the
local PE 
	4.	Targeted LDP session is restored but an attempt of the
local PE to restore the PW fails since there is no remote peer anymore.
What should now happen to the local AC?

	Remember that Luca sent an email to the list proposing to add a
BFD code point to indicate that an AC was taken down for admistrative
reasons. That proposal was driven by the same motivation.
	[[Sasha]] I remember that, and I believe I've sent a couple of
messages to the list questioning the rationale of such a code point.  
	 
	Peter

		From: Alexander Vainshtein
[mailto:[email-masked]] 
		Sent: Monday, January 05, 2009 5:12 AM
		To: Aissaoui, Mustapha (Mustapha); Busschbach, Peter B
(Peter); [email-masked]; [email-masked]; Thomas D. Nadeau;
[email-masked]
		Cc: [email-masked]; Shell Nakash; Prashant Desai; Igor
Danilovich; Itamar Levy
		Subject: A question regarding torn down PWs in
draft-ietf-pwe3-oam-msg-map-08.txt

		Hi Monique/Mustapha/Peter/Dave/Thom/Luca,
		I have a question to you as the editors of the expired)
draft-ietf-pwe3-oam-msg-map-08.txt.
		The question is related to the following text in Section
8.2.1. PW Forward Defect State Entry/Exit Criteria:
		<quote>

			   Note that if the PW control session between
the PEs fails, the PW is 
			   torn down and needs to be re-established.
This includes failure of 
			   the T-LDP session, the L2TP session, or the
L2TP control connection. 
			   However, the consequent actions towards the
ACs are the same as if 
			   the PW entered the forward defect state.

		<end quote>
		The PW may be torn down not just because the PW control
session between the PEs fails. E.g., the PW can be deleted by the
operator in one of the PEs.
		Does the quoted text imply that implementations must
distinguish between PWs being torn down due to failures of their control
sessions and PWs that are torn down for any other reason?
		The use case of special interest would be a PW that has
been set up (and later torn down) using a single-sided mechanism...
		I'd also like to note that there are several references
in the draft to unspecified defects  "that do not result in the PW being
torn down"...
		 
		Regards,
		     Sasha

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Mon, 5 Jan 2009 10:37:11 -0600

Dave,
 
I seem to remember from discussions in ITU-T about Ethernet OAM that an
administrative action should not result in AIS insertion. To be honest,
I can't remember why, though. Therefore, unless someone else knows a
reason why administrative down should not result in AIS, I withdraw my
comment.
 
Peter

	From: David Allan [mailto:[email-masked]] 
	Sent: Monday, January 05, 2009 11:16 AM
	To: Alexander Vainshtein; Busschbach, Peter B (Peter)
	Cc: [email-masked]; Shell Nakash; Prashant Desai; Igor
Danilovich; Itamar Levy; Aissaoui, Mustapha (Mustapha);
[email-masked]; Thomas D. Nadeau; [email-masked]
	Subject: RE: A question regarding torn down PWs in
draft-ietf-pwe3-oam-msg-map-08.txt

	hi Peter:
	 
	Below you suggest that FDI not be inserted when a PW is taken
down administratively. I do not understand why this is different from
any other disruption of connectivity, unless it is beleived that an
administrative action is joined up across both MPLS PWs and the native
service by other means....
	 
	Am I missing somthing?
	 
	cheers
	Dave

	 

	From: Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: Monday, January 05, 2009 10:09 AM
	To: Busschbach, Peter B (Peter)
	Cc: [email-masked]; Shell Nakash; Prashant Desai; Igor
Danilovich; Itamar Levy; Aissaoui, Mustapha (Mustapha); Allan, David
(CAR:NS00); [email-masked]; Thomas D. Nadeau; [email-masked]
	Subject: RE: A question regarding torn down PWs in
draft-ietf-pwe3-oam-msg-map-08.txt

	Peter hi,

	Regards,
	    Sasha

		Hi Sasha,
		 
		>> Does the quoted text imply that implementations must
distinguish between PWs being torn down
		>> due to failures of their control sessions and PWs
that are torn down for any other reason?
		 
		Whether PWs are torn down because of a defect (whether
it is in the control plane or in the data plane), the consequent actions
are the same.

		1.	A PW is set up 
anymore. What should now happen to the local AC?

		Remember that Luca sent an email to the list proposing
to add a BFD code point to indicate that an AC was taken down for
admistrative reasons. That proposal was driven by the same motivation.
		[[Sasha]] I remember that, and I believe I've sent a
couple of messages to the list questioning the rationale of such a code
point.  
		 
		Peter

			From: Alexander Vainshtein
[mailto:[email-masked]] 
			Sent: Monday, January 05, 2009 5:12 AM
			To: Aissaoui, Mustapha (Mustapha); Busschbach,
Peter B (Peter); [email-masked]; [email-masked]; Thomas D.
Nadeau; [email-masked]
			Cc: [email-masked]; Shell Nakash; Prashant Desai;
Igor Danilovich; Itamar Levy
			Subject: A question regarding torn down PWs in
draft-ietf-pwe3-oam-msg-map-08.txt

			Hi Monique/Mustapha/Peter/Dave/Thom/Luca,
			I have a question to you as the editors of the
expired) draft-ietf-pwe3-oam-msg-map-08.txt.
			The question is related to the following text in
Section 8.2.1. PW Forward Defect State Entry/Exit Criteria:
			<quote>

				   Note that if the PW control session
between the PEs fails, the PW is 
				   torn down and needs to be
re-established. This includes failure of 
				   the T-LDP session, the L2TP session,
or the L2TP control connection. 
				   However, the consequent actions
towards the ACs are the same as if 
				   the PW entered the forward defect
state.

			<end quote>
			The PW may be torn down not just because the PW
control session between the PEs fails. E.g., the PW can be deleted by
the operator in one of the PEs.
			Does the quoted text imply that implementations
must distinguish between PWs being torn down due to failures of their
control sessions and PWs that are torn down for any other reason?
			The use case of special interest would be a PW
that has been set up (and later torn down) using a single-sided
mechanism...
			I'd also like to note that there are several
references in the draft to unspecified defects  "that do not result in
the PW being torn down"...
			 
			Regards,
			     Sasha

---

From: <[email-masked]>
Date: Mon, 5 Jan 2009 18:11:22 -0000

Peter,
 
I think I can answer your question wrt Ethernet at least.  AID/FDI has
no meaning whatsoever to a client cl-ps layer network....this is why
IEEE did not have AIS/FDI in 802.1ag.  
 
And as an aside:  AIS/FDI is almost essential/mandated in a co-cs layer
network...in the absence of traffic something MUST be sent in such
networks, and AIS/FDI = all 1s here is a throwback to TTL logic that
floated to binary 1 (+5V) under failures.  The merit of AIS/FDI is
debateable in a co-ps mode network.  However, in a cl-ps layer network
it has no meaning at all......since there is no server (connection) to
client (*connection*) association.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Busschbach, Peter B (Peter)
	Sent: 05 January 2009 16:37
	To: David Allan; Alexander Vainshtein
	Cc: Shell Nakash; [email-masked]; [email-masked]; Igor
Danilovich; [email-masked]; Aissaoui, Mustapha (Mustapha); Itamar Levy
	Subject: Re: [PWE3] A question regarding torn down PWs
indraft-ietf-pwe3-oam-msg-map-08.txt

	Dave,
	 
	I seem to remember from discussions in ITU-T about Ethernet OAM
that an administrative action should not result in AIS insertion. To be
honest, I can't remember why, though. Therefore, unless someone else
knows a reason why administrative down should not result in AIS, I
withdraw my comment.
	 
	Peter

		hi Peter:
		 
		Below you suggest that FDI not be inserted when a PW is
taken down administratively. I do not understand why this is different
from any other disruption of connectivity, unless it is beleived that an
administrative action is joined up across both MPLS PWs and the native
service by other means....
		 
		Am I missing somthing?
		 
		cheers
		Dave

		 

		Peter hi,

		Regards,
		    Sasha

			From: Busschbach, Peter B (Peter)
[mailto:[email-masked]] 
			Sent: Monday, January 05, 2009 3:51 PM
			To: Alexander Vainshtein; Aissaoui, Mustapha
(Mustapha); [email-masked]; [email-masked]; Thomas D. Nadeau;
[email-masked]
			Cc: [email-masked]; Shell Nakash; Prashant Desai;
Igor Danilovich; Itamar Levy
			Subject: RE: A question regarding torn down PWs
in draft-ietf-pwe3-oam-msg-map-08.txt

			Hi Sasha,
			 
			>> Does the quoted text imply that
implementations must distinguish between PWs being torn down
			>> due to failures of their control sessions and
PWs that are torn down for any other reason?
			 
			Whether PWs are torn down because of a defect
(whether it is in the control plane or in the data plane), the
consequent actions are the same.
			[[Sasha]] I am not aware of the case when a PW
is torn down due to defects in the data plane. Could you please provide
a reference/an example?
			 It would be good, however, if a PE would be
able to distinguish between PWs torn down because of defects and PWs
torn down for administrative reasons, because in the latter case there
is no need to insert an FDI message downstream.
			[[Sasha]] I do not think that RFC 4447 provides
for that. In addition, please consider the following scenario:

			1.	A PW is set up 
			2.	The PW is torn down due to the CP defect
(targeted LDP session went down). FDI is inserted in the local AC 
			3.	 The user has deleted the PW end point
in the remote PE. Since the LDP session is down, this fact is not
communicated to the local PE 
			4.	Targeted LDP session is restored but an
attempt of the local PE to restore the PW fails since there is no remote
peer anymore. What should now happen to the local AC?

			Remember that Luca sent an email to the list
proposing to add a BFD code point to indicate that an AC was taken down
for admistrative reasons. That proposal was driven by the same
motivation.
			[[Sasha]] I remember that, and I believe I've
sent a couple of messages to the list questioning the rationale of such
a code point.  
			 
			Peter

				From: Alexander Vainshtein
[mailto:[email-masked]] 
				Sent: Monday, January 05, 2009 5:12 AM
				To: Aissaoui, Mustapha (Mustapha);
Busschbach, Peter B (Peter); [email-masked]; [email-masked];
Thomas D. Nadeau; [email-masked]
				Cc: [email-masked]; Shell Nakash;
Prashant Desai; Igor Danilovich; Itamar Levy
				Subject: A question regarding torn down
PWs in draft-ietf-pwe3-oam-msg-map-08.txt

				Hi
Monique/Mustapha/Peter/Dave/Thom/Luca,
				I have a question to you as the editors
of the expired) draft-ietf-pwe3-oam-msg-map-08.txt.
				The question is related to the following
text in Section 8.2.1. PW Forward Defect State Entry/Exit Criteria:
				<quote>

				<end quote>
				The PW may be torn down not just because
the PW control session between the PEs fails. E.g., the PW can be
deleted by the operator in one of the PEs.
				Does the quoted text imply that
implementations must distinguish between PWs being torn down due to
failures of their control sessions and PWs that are torn down for any
other reason?
				The use case of special interest would
be a PW that has been set up (and later torn down) using a single-sided
mechanism...
				I'd also like to note that there are
several references in the draft to unspecified defects  "that do not
result in the PW being torn down"...
				 
				Regards,
				     Sasha

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Mon, 5 Jan 2009 13:09:22 -0600

Hi Neil,
 
Not sure why you believe Ethernet is a cl-ps network. It can be, but
does not have to. Consequently, Y.1731 does have AIS.
 
My memory of the AIS discussion may be faulty, but it was not because of
anything specific to Ethernet.
 
Peter

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Monday, January 05, 2009 1:11 PM
	To: Busschbach, Peter B (Peter); [email-masked];
[email-masked]
	Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; Aissaoui,
Mustapha (Mustapha); [email-masked]
	Subject: RE: [PWE3] A question regarding torn down PWs
indraft-ietf-pwe3-oam-msg-map-08.txt

	Peter,
	 
	I think I can answer your question wrt Ethernet at least.
AID/FDI has no meaning whatsoever to a client cl-ps layer
network....this is why IEEE did not have AIS/FDI in 802.1ag.  
	 
	And as an aside:  AIS/FDI is almost essential/mandated in a
co-cs layer network...in the absence of traffic something MUST be sent
in such networks, and AIS/FDI = all 1s here is a throwback to TTL logic
that floated to binary 1 (+5V) under failures.  The merit of AIS/FDI is
debateable in a co-ps mode network.  However, in a cl-ps layer network
it has no meaning at all......since there is no server (connection) to
client (*connection*) association.
	 
	regards, Neil

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Busschbach, Peter B (Peter)
		Sent: 05 January 2009 16:37
		To: David Allan; Alexander Vainshtein
		Cc: Shell Nakash; [email-masked]; [email-masked];
Igor Danilovich; [email-masked]; Aissaoui, Mustapha (Mustapha); Itamar
Levy
		Subject: Re: [PWE3] A question regarding torn down PWs
indraft-ietf-pwe3-oam-msg-map-08.txt

		Dave,
		 
		I seem to remember from discussions in ITU-T about
Ethernet OAM that an administrative action should not result in AIS
insertion. To be honest, I can't remember why, though. Therefore, unless
someone else knows a reason why administrative down should not result in
AIS, I withdraw my comment.
		 
		Peter

			From: David Allan [mailto:[email-masked]] 
			Sent: Monday, January 05, 2009 11:16 AM
			To: Alexander Vainshtein; Busschbach, Peter B
(Peter)
			Cc: [email-masked]; Shell Nakash; Prashant Desai;
Igor Danilovich; Itamar Levy; Aissaoui, Mustapha (Mustapha);
[email-masked]; Thomas D. Nadeau; [email-masked]
			Subject: RE: A question regarding torn down PWs
in draft-ietf-pwe3-oam-msg-map-08.txt

			hi Peter:
			 
			Below you suggest that FDI not be inserted when
a PW is taken down administratively. I do not understand why this is
different from any other disruption of connectivity, unless it is
beleived that an administrative action is joined up across both MPLS PWs
and the native service by other means....
			 
			Am I missing somthing?
			 
			cheers
			Dave

			 

			From: Alexander Vainshtein
[mailto:[email-masked]] 
			Sent: Monday, January 05, 2009 10:09 AM
			To: Busschbach, Peter B (Peter)
			Cc: [email-masked]; Shell Nakash; Prashant Desai;
Igor Danilovich; Itamar Levy; Aissaoui, Mustapha (Mustapha); Allan,
David (CAR:NS00); [email-masked]; Thomas D. Nadeau;
[email-masked]
			Subject: RE: A question regarding torn down PWs
in draft-ietf-pwe3-oam-msg-map-08.txt

			Peter hi,
			 
			Please see some comments inline below (blue
italics).
			 
			Regards,
			    Sasha

				From: Busschbach, Peter B (Peter)
[mailto:[email-masked]] 
				Sent: Monday, January 05, 2009 3:51 PM
				To: Alexander Vainshtein; Aissaoui,
Mustapha (Mustapha); [email-masked]; [email-masked]; Thomas D.
Nadeau; [email-masked]
				Cc: [email-masked]; Shell Nakash;
Prashant Desai; Igor Danilovich; Itamar Levy
				Subject: RE: A question regarding torn
down PWs in draft-ietf-pwe3-oam-msg-map-08.txt

				Hi Sasha,
				 
				>> due to failures of their control
				 
				Whether PWs are torn down because of a
defect (whether it is in the control plane or in the data plane), the
consequent actions are the same.
				[[Sasha]] I am not aware of the case
when a PW is torn down due to defects in the data plane. Could you
please provide a reference/an example?
				 It would be good, however, if a PE
would be able to distinguish between PWs torn down because of defects
and PWs torn down for administrative reasons, because in the latter case
there is no need to insert an FDI message downstream.
				[[Sasha]] I do not think that RFC 4447
provides for that. In addition, please consider the following scenario:

				1.	A PW is set up 
				2.	The PW is torn down due to the
CP defect (targeted LDP session went down). FDI is inserted in the local
AC 
				3.	 The user has deleted the PW end
point in the remote PE. Since the LDP session is down, this fact is not
communicated to the local PE 
				4.	Targeted LDP session is restored
but an attempt of the local PE to restore the PW fails since there is no
remote peer anymore. What should now happen to the local AC?

				Remember that Luca sent an email to the
list proposing to add a BFD code point to indicate that an AC was taken
down for admistrative reasons. That proposal was driven by the same
motivation.
				[[Sasha]] I remember that, and I believe
I've sent a couple of messages to the list questioning the rationale of
such a code point.  
				 
				Peter

				Hi

				<end quote>
				 
				Regards,
				     Sasha

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 05 Jan 2009 21:30:21 +0100

Hello Peter,

You wrote:

> administrative action should not result in AIS insertion. 

That is correct in this case a LCK PDU will be inserted.

AIS/FDI PDUs are inserted only as a consequent action to detected
server defects.

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: <[email-masked]>
Date: Mon, 5 Jan 2009 20:45:34 -0000

Thanks Peter,
 
Native/original Ethernet (.1D, .1Q and .1ad) are all cl-ps...and all are
a single layer network.  PBB (.1ah) is also cl-ps....but introduces true
C/S layering, ie 2 functionally independemt layer networks.  PBB-TE
(.1ay) is however most definitely co-ps...though in principle it does
not need the MACinMAC restriction to be co-ps.
 
However, the only key point here is the merit of injecting an FDI into a
client layer network.  If the client layer network is cl-ps then
injecting FDI into it makes no sense at all.  If you think it does then
maybe IP should also use it ;-)  
 
The reason FDI exists in Y.1731 is because some folks think *imposing* a
forced topology of nested MEPs is a good idea...we don't, but that (ie
TCM) is a different issue.  Bottom line is cl-ps networks cannot make
sense of FDI in a *traffic sense*.
 
regards, Neil

	Sent: 05 January 2009 19:09
	To: Harrison,N,Neil,CXM R; [email-masked];

	Hi Neil,
	 
	Not sure why you believe Ethernet is a cl-ps network. It can be,
but does not have to. Consequently, Y.1731 does have AIS.
	 
	My memory of the AIS discussion may be faulty, but it was not
because of anything specific to Ethernet.
	 
	Peter

		From: [email-masked]
[mailto:[email-masked]] 

		Peter,
		 
		I think I can answer your question wrt Ethernet at
least.  AID/FDI has no meaning whatsoever to a client cl-ps layer
network....this is why IEEE did not have AIS/FDI in 802.1ag.  
		 
		And as an aside:  AIS/FDI is almost essential/mandated
in a co-cs layer network...in the absence of traffic something MUST be
sent in such networks, and AIS/FDI = all 1s here is a throwback to TTL
logic that floated to binary 1 (+5V) under failures.  The merit of
AIS/FDI is debateable in a co-ps mode network.  However, in a cl-ps
layer network it has no meaning at all......since there is no server
(connection) to client (*connection*) association.
		 
		regards, Neil

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Busschbach, Peter B (Peter)
			Sent: 05 January 2009 16:37
			To: David Allan; Alexander Vainshtein
			Cc: Shell Nakash; [email-masked];
[email-masked]; Igor Danilovich; [email-masked]; Aissaoui, Mustapha
(Mustapha); Itamar Levy
			Subject: Re: [PWE3] A question regarding torn
down PWs indraft-ietf-pwe3-oam-msg-map-08.txt

			Dave,
			 
			I seem to remember from discussions in ITU-T
about Ethernet OAM that an administrative action should not result in
AIS insertion. To be honest, I can't remember why, though. Therefore,
unless someone else knows a reason why administrative down should not
result in AIS, I withdraw my comment.
			 
			Peter

				From: David Allan
[mailto:[email-masked]] 
				Sent: Monday, January 05, 2009 11:16 AM
				To: Alexander Vainshtein; Busschbach,
Peter B (Peter)
				Cc: [email-masked]; Shell Nakash;
Prashant Desai; Igor Danilovich; Itamar Levy; Aissaoui, Mustapha
(Mustapha); [email-masked]; Thomas D. Nadeau; [email-masked]
				Subject: RE: A question regarding torn
down PWs in draft-ietf-pwe3-oam-msg-map-08.txt

				hi Peter:
				 
				Below you suggest that FDI not be
inserted when a PW is taken down administratively. I do not understand
why this is different from any other disruption of connectivity, unless
it is beleived that an administrative action is joined up across both
MPLS PWs and the native service by other means....
				 
				Am I missing somthing?
				 
				cheers
				Dave

				 

Prashant Desai; Igor Danilovich; Itamar Levy; Aissaoui, Mustapha
(Mustapha); Allan, David (CAR:NS00); [email-masked]; Thomas D.

				Peter hi,
				 
				Please see some comments inline below
(blue italics).
				 
				Regards,
				    Sasha

				Hi Sasha,

				1.	A PW is set up 

				Peter

				Hi

				<end quote>
				 
				Regards,
				     Sasha

---

From: "David Allan" <[email-masked]>
Date: Mon, 5 Jan 2009 16:41:08 -0500

Hi Huub:

It seems to me that an administrative modification to a PW would not
generate the appropriate 1731 PDUs as it is not the Ethernet MEP....(and
we have not defined IWF beyond notifications and going further could get
truly ugly... ;-)

So an administrative action on a PW would appear as a defect to the
client layer... (?) 

An administrative action on the client trail would work correctly as it
would simply be relayed without modification by the PW that formed part
of the overall trail....

Would that agree with your understanding?

Cheers
Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Huub van Helvoort
Sent: Monday, January 05, 2009 3:30 PM
To: Busschbach, Peter B (Peter)
Cc: [email-masked]
Subject: Re: [PWE3] A question regarding torn down PWsin
draft-ietf-pwe3-oam-msg-map-08.txt

Hello Peter,

You wrote:

> I seem to remember from discussions in ITU-T about Ethernet OAM that 
> an administrative action should not result in AIS insertion.

AIS/FDI PDUs are inserted only as a consequent action to detected server
defects.

Cheers, Huub.

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Mon, 5 Jan 2009 16:54:37 -0600

Peter and Sasha,
yes an admin down of the PW should result in the PW being torn down, as
opposed to sending a status TLV, and a defect indication being sent over
the AC. 
 
The draft however does not preclude implementations from offering an
option to suppress defect over the AC if deemed useful.
 
As for the "PW not forwarding" status TLV codepoint, and the BFD
equivalent one Luca asked in the mailing list, it is mostly used when
you want to signal defects, other than the AC and PW down ones, which do
not result in the PW being torn down. Thus, bringing down the PW
administratively is not one such a case. I do not think there is any
explicit specification how to use this codepoint but we use it in our
implementation for signaling defects such as when the operational MTU of
the LSP tunnel changes and does not match anymore the value signaled in
the PW interface parameters.
 
Regards,
Mustapha.

	From: Busschbach, Peter B (Peter)
[mailto:[email-masked]] 
	Sent: Monday, January 05, 2009 11:37 AM
	To: David Allan; Alexander Vainshtein
	Cc: [email-masked]; Shell Nakash; Prashant Desai; Igor
Danilovich; Itamar Levy; AISSAOUI Mustapha; [email-masked]; Thomas
D. Nadeau; [email-masked]
	Subject: RE: A question regarding torn down PWs in
draft-ietf-pwe3-oam-msg-map-08.txt

	Dave,

	Peter

		hi Peter:

		Am I missing somthing?
		 
		cheers
		Dave

		 

		Peter hi,

		Regards,
		    Sasha

			Hi Sasha,

			1.	A PW is set up 

			Peter

				Hi

				<end quote>
				 
				Regards,
				     Sasha

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 06 Jan 2009 00:21:40 +0100

Hello Dave,

You replied:

> generate the appropriate 1731 PDUs as it is not the Ethernet MEP....

Indeed. I answered the question regarding Ethernet OAM.

> So an administrative action on a PW would appear as a defect to the

Yes.

> would simply be relayed without modification by the PW that formed part

OK.

> Would that agree with your understanding?

Indeed.

Cheers, Huub.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 6 Jan 2009 13:57:54 +0200

Peter,
I see that I have been wrong when I've said that 4447 does not allow differentiation between PW teardown due to defects and any other case of the PW teardown. In fact, it does by allocating a dedicated LDP status code 0x0000002B  - "Label Withdraw PW Status Method Not Supported"   that must be used in the Label Release Message if the PW is torn down due to defects. 4447 describes this as an optional method for equipment that does not support PW Status TLV.

Regarding the example, please note that the PWs can be set up in a single-ended manner using FEX 129. I would expect that, in this case, the users would presumably delete them in a single-ended way as well, initiating the teardown process at the same PE that has been used to set it up. This explains (hopefully) why in certain situations the user would remove the PW at one end only.

If this explanation makes sense, then the problem I see with my example is easy to understand:

 *   If the PW is torn down while the CP is OK, the remote PE would not insert any AIS/FDI into its local AC
 *   If the PW is torn down while the CP is not operational (the targeted LDP session is down), then AIS/FDI insertion (activated by the CP failure) would persist until such time when the user deletes its endpoint in the other PE
 *   The bottom line: the behavior of the PW endpoint depends on the actual sequence of events. This does not look healthy to me.

Hopefully this clarifies the situation.

Regards,
     Sasha
________________________________
From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
Sent: Monday, January 05, 2009 6:13 PM
To: Alexander Vainshtein
Cc: [email-masked]; Shell Nakash; Prashant Desai; Igor Danilovich; Itamar Levy; Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]; Thomas D. Nadeau; [email-masked]
Subject: RE: A question regarding torn down PWs in draft-ietf-pwe3-oam-msg-map-08.txt

Sasha,

Please see in-line

[snipped]

[PB]  See section 5.4.1 of RFC 4447: a simple label withdraw method MAY also be
   supported as a legacy means of signaling PW status and AC status

 1.  A PW is set up
 2.  The PW is torn down due to the CP defect (targeted LDP session went down). FDI is inserted in the local AC
 3.   The user has deleted the PW end point in the remote PE. Since the LDP session is down, this fact is not communicated to the local PE
 4.  Targeted LDP session is restored but an attempt of the local PE to restore the PW fails since there is no remote peer anymore. What should now happen to the local AC

[PB] I don't understand the example. Who is the user that removes the PW end point? A service provider? If so, why would that service provider update one PE to remove the PW but not the peer?

In any case, if the local PE is inserting FDI messages periodically on the local AC, it will continue doing so as long as the PW is not restored. Do you believe it should behave otherwise?

[snipped to the end]

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Tue, 6 Jan 2009 11:48:58 -0600

Sasha,
 
First of all, my original email to you was incorrect. I wrote that in
the case of administrative down, the PE should not insert FDI/AIS, but
as Dave pointed out, it should.
 
Secondly, I still don't understand what you think is problematic in the
example that you give. There are two cases:
 
1) The control plane is up. The local PE informs the remote PE that the
PW is to be torn down.
 
2) The control plane is down. The local PE has to wait for the control
plane to come up before it can inform the remote PE that the PW is to be
torn down. In the mean time, the remote PE performs the consequent
actions associated with the defect condition, i.e. it inserts AIS on the
AC.
 
What is the problem?
 
Peter

	Sent: Tuesday, January 06, 2009 6:58 AM

	Peter,
	I see that I have been wrong when I've said that 4447 does not
allow differentiation between PW teardown due to defects and any other
case of the PW teardown. In fact, it does by allocating a dedicated LDP
status code 0x0000002B  - "Label Withdraw PW Status Method Not
Supported"   that must be used in the Label Release Message if the PW is
torn down due to defects. 4447 describes this as an optional method for
equipment that does not support PW Status TLV.

	Regarding the example, please note that the PWs can be set up in
a single-ended manner using FEX 129. I would expect that, in this case,
the users would presumably delete them in a single-ended way as well,
initiating the teardown process at the same PE that has been used to set
it up. This explains (hopefully) why in certain situations the user
would remove the PW at one end only. 
	 
	If this explanation makes sense, then the problem I see with my
example is easy to understand:

	*	If the PW is torn down while the CP is OK, the remote PE
would not insert any AIS/FDI into its local AC 
	*	If the PW is torn down while the CP is not operational
(the targeted LDP session is down), then AIS/FDI insertion (activated by
the CP failure) would persist until such time when the user deletes its
endpoint in the other PE 
	*	The bottom line: the behavior of the PW endpoint depends
on the actual sequence of events. This does not look healthy to me.

	Regards,
	     Sasha

		Sasha,
		 
		Please see in-line

			
			[snipped] 

				
				[PB]  See section 5.4.1 of RFC 4447: a
simple label withdraw method MAY also be
				   supported as a legacy means of
signaling PW status and AC status

				1.	A PW is set up 
remote peer anymore. What should now happen to the local AC

				[PB] I don't understand the example. Who
is the user that removes the PW end point? A service provider? If so,
why would that service provider update one PE to remove the PW but not
the peer? 
				 
				In any case, if the local PE is
inserting FDI messages periodically on the local AC, it will continue
doing so as long as the PW is not restored. Do you believe it should
behave otherwise?
				 
				[snipped to the end]

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 6 Jan 2009 21:55:44 +0200

Peter,
I do not think we have a standard method to indicate to the peer PE that the PW is administratively down.
The only more or less suitable statement I've found in 4477 says:
<quote>
The PW label should not be withdrawn unless the operator administratively configures the pseudowire down (or the PW configuration is deleted entirely).
<end quote>,

This statement seems to indicate that if a PW is administratively disabled, PW labels must be withdrawn (released?). But there are no dedicated error codes that could be used in the Label Release/Label Withdraw messages  and no PW status bits either. (Mustapha's comment on the use of the "PW not forwarding" code point seems to support my opinion).

Regarding the example: what you say means that the PE that has been used to set up the PW and where the PW end point has been deleted while CP was down must remember an already non-existing PW end point and update the peer about its deletion when this becomes possible. I do not think that this kind of behavior is defined anywhere, but maybe I've missed something?

Regards,
     Sasha

Sent: Tuesday, January 06, 2009 7:49 PM

Sasha,

First of all, my original email to you was incorrect. I wrote that in the case of administrative down, the PE should not insert FDI/AIS, but as Dave pointed out, it should.

Secondly, I still don't understand what you think is problematic in the example that you give. There are two cases:

1) The control plane is up. The local PE informs the remote PE that the PW is to be torn down.

2) The control plane is down. The local PE has to wait for the control plane to come up before it can inform the remote PE that the PW is to be torn down. In the mean time, the remote PE performs the consequent actions associated with the defect condition, i.e. it inserts AIS on the AC.

What is the problem?

Peter

Peter,

Regards,
     Sasha

Sasha,

Please see in-line

[snipped]

 1.  A PW is set up

[snipped to the end]

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Tue, 6 Jan 2009 15:02:04 -0600

>> the PE that has been used to set up the PW and where the PW end point
has been deleted while CP
>> was down must remember an already non-existing PW end point and
update the peer about its deletion
>> when this becomes possible
 
Sasha,
 
I don't see how a PE can delete a PW without sending a Label Withdraw or
Label Release message to its peer. If the control plane is down and this
message cannot be sent, the PW cannot be deleted. Therefore, IMO there
is no such thing as a non-existent PW that must be remembered. 
 
Is your understanding of the PW release procedure different?
 
Peter

	Sent: Tuesday, January 06, 2009 2:56 PM

	Peter,
	I do not think we have a standard method to indicate to the peer
PE that the PW is administratively down.
	The only more or less suitable statement I've found in 4477
says:
	<quote>

		The PW label should not be withdrawn unless the operator
administratively configures the pseudowire down (or the PW configuration
is deleted entirely).

	<end quote>,
	 
	This statement seems to indicate that if a PW is
administratively disabled, PW labels must be withdrawn (released?). But
there are no dedicated error codes that could be used in the Label
Release/Label Withdraw messages  and no PW status bits either.
(Mustapha's comment on the use of the "PW not forwarding" code point
seems to support my opinion). 
	 
	Regarding the example: what you say means that the PE that has
been used to set up the PW and where the PW end point has been deleted
while CP was down must remember an already non-existing PW end point and
update the peer about its deletion when this becomes possible. I do not
think that this kind of behavior is defined anywhere, but maybe I've
missed something?
	 
	Regards,
	     Sasha

		Sasha,
		 
		First of all, my original email to you was incorrect. I
wrote that in the case of administrative down, the PE should not insert
FDI/AIS, but as Dave pointed out, it should.
		 
		Secondly, I still don't understand what you think is
problematic in the example that you give. There are two cases:
		 
		1) The control plane is up. The local PE informs the
remote PE that the PW is to be torn down.
		 
		2) The control plane is down. The local PE has to wait
for the control plane to come up before it can inform the remote PE that
the PW is to be torn down. In the mean time, the remote PE performs the
consequent actions associated with the defect condition, i.e. it inserts
AIS on the AC.
		 
		What is the problem?
		 
		Peter

			Peter,
			I see that I have been wrong when I've said that
4447 does not allow differentiation between PW teardown due to defects
and any other case of the PW teardown. In fact, it does by allocating a
dedicated LDP status code 0x0000002B  - "Label Withdraw PW Status Method
Not Supported"   that must be used in the Label Release Message if the
PW is torn down due to defects. 4447 describes this as an optional
method for equipment that does not support PW Status TLV.

			Regarding the example, please note that the PWs
can be set up in a single-ended manner using FEX 129. I would expect
that, in this case, the users would presumably delete them in a
single-ended way as well, initiating the teardown process at the same PE
that has been used to set it up. This explains (hopefully) why in
certain situations the user would remove the PW at one end only. 
			 
			If this explanation makes sense, then the
problem I see with my example is easy to understand:

			*	If the PW is torn down while the CP is
OK, the remote PE would not insert any AIS/FDI into its local AC 
			*	If the PW is torn down while the CP is
not operational (the targeted LDP session is down), then AIS/FDI
insertion (activated by the CP failure) would persist until such time
when the user deletes its endpoint in the other PE 
			*	The bottom line: the behavior of the PW
endpoint depends on the actual sequence of events. This does not look
healthy to me.

			Regards,
			     Sasha

				Sasha,
				 
				Please see in-line

				
				[snipped] 

				

				1.	A PW is set up 

				 
				 
				[snipped to the end]