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

["Busschbach, Peter B \(Peter\)" <[e-mail]>]

>> 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


________________________________

	From: Alexander Vainshtein
[mailto:[e-mail]] 
	Sent: Tuesday, January 06, 2009 2:56 PM
	To: Busschbach, Peter B (Peter)
	Cc: [e-mail]; Shell Nakash; Prashant Desai; Igor
Danilovich; Itamar Levy; Aissaoui, Mustapha (Mustapha);
[e-mail]; [e-mail]; Thomas D. Nadeau;
[e-mail]
	Subject: RE: A question regarding torn down PWs in
draft-ietf-pwe3-oam-msg-map-08.txt
	
	
	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


________________________________

		From: Busschbach, Peter B (Peter)
[mailto:[e-mail]] 
		Sent: Tuesday, January 06, 2009 7:49 PM
		To: Alexander Vainshtein
		Cc: [e-mail]; Shell Nakash; Prashant Desai; Igor
Danilovich; Itamar Levy; Aissaoui, Mustapha (Mustapha);
[e-mail]; [e-mail]; Thomas D. Nadeau;
[e-mail]
		Subject: RE: A question regarding torn down PWs in
draft-ietf-pwe3-oam-msg-map-08.txt
		
		
		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


________________________________

			From: Alexander Vainshtein
[mailto:[e-mail]] 
			Sent: Tuesday, January 06, 2009 6:58 AM
			To: Busschbach, Peter B (Peter)
			Cc: [e-mail]; Shell Nakash; Prashant Desai;
Igor Danilovich; Itamar Levy; Aissaoui, Mustapha (Mustapha);
[e-mail]; [e-mail]; Thomas D. Nadeau;
[e-mail]
			Subject: RE: A question regarding torn down PWs
in draft-ietf-pwe3-oam-msg-map-08.txt
			
			
			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:[e-mail]] 
			Sent: Monday, January 05, 2009 6:13 PM
			To: Alexander Vainshtein
			Cc: [e-mail]; Shell Nakash; Prashant Desai;
Igor Danilovich; Itamar Levy; Aissaoui, Mustapha (Mustapha);
[e-mail]; [e-mail]; Thomas D. Nadeau;
[e-mail]
			Subject: RE: A question regarding torn down PWs
in draft-ietf-pwe3-oam-msg-map-08.txt
			
			

				Sasha,
				 
				Please see in-line


________________________________

				From: Alexander Vainshtein
[mailto:[e-mail]] 
				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]

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