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

[Alexander Vainshtein <[e-mail]>]

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