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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Tue, 06 January 2009 11:58 UTC

Return-Path: <pwe3-bounces@ietf.org>
X-Original-To: pwe3-archive@megatron.ietf.org
Delivered-To: ietfarch-pwe3-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2363A67FC; Tue, 6 Jan 2009 03:58:14 -0800 (PST)
X-Original-To: pwe3@core3.amsl.com
Delivered-To: pwe3@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6662B3A67FC for <pwe3@core3.amsl.com>; Tue, 6 Jan 2009 03:58:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level:
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KscIyr1bO+As for <pwe3@core3.amsl.com>; Tue, 6 Jan 2009 03:58:12 -0800 (PST)
Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 2900C3A6768 for <pwe3@ietf.org>; Tue, 6 Jan 2009 03:58:10 -0800 (PST)
Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 06 Jan 2009 14:21:51 +0200
Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 13:57:56 +0200
Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 6 Jan 2009 13:57:56 +0200
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Busschbach, Peter B (Peter)" <busschbach@alcatel-lucent.com>
Date: Tue, 06 Jan 2009 13:57:54 +0200
Thread-Topic: A question regarding torn down PWs in draft-ietf-pwe3-oam-msg-map-08.txt
Thread-Index: AclvHgFatl4xVjfUTBai2RqcqunEfwAHTX0AAADXDMAABCCuAAAiuSoA
Message-ID: <A3C5DF08D38B6049839A6F553B331C7698C34E3EE3@ILPTMAIL02.ecitele.com>
References: <A3C5DF08D38B6049839A6F553B331C7698C2C6CCC1@ILPTMAIL02.ecitele.com> <E60778C3916D3548BBCF4D964186348F022953BD@ILEXC2U01.ndc.lucent.com> <A3C5DF08D38B6049839A6F553B331C7698C2C6CDE7@ILPTMAIL02.ecitele.com> <E60778C3916D3548BBCF4D964186348F022954DD@ILEXC2U01.ndc.lucent.com>
In-Reply-To: <E60778C3916D3548BBCF4D964186348F022954DD@ILEXC2U01.ndc.lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Jan 2009 11:57:56.0880 (UTC) FILETIME=[038A4100:01C96FF6]
Cc: Shell Nakash <Shell.Nakash@ecitele.com>, "lmartini@cisco.com" <lmartini@cisco.com>, "mmorrow@cisco.com" <mmorrow@cisco.com>, Igor Danilovich <Igor.Danilovich@ecitele.com>, "pwe3@ietf.org" <pwe3@ietf.org>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, Itamar Levy <Itamar.Levy@ecitele.com>
Subject: Re: [PWE3] A question regarding torn down PWs in draft-ietf-pwe3-oam-msg-map-08.txt
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0655282542=="
Sender: pwe3-bounces@ietf.org
Errors-To: pwe3-bounces@ietf.org

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:busschbach@alcatel-lucent.com]
Sent: Monday, January 05, 2009 6:13 PM
To: Alexander Vainshtein
Cc: pwe3@ietf.org; Shell Nakash; Prashant Desai; Igor Danilovich; Itamar Levy; Aissaoui, Mustapha (Mustapha); dallan@nortel.com; lmartini@cisco.com; Thomas D. Nadeau; mmorrow@cisco.com
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:Alexander.Vainshtein@ecitele.com]
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
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3