Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock

Martin Vigoureux <martin.vigoureux@alcatel-lucent.com> Mon, 04 May 2009 18:57 UTC

Return-Path: <Martin.Vigoureux@alcatel-lucent.com>
X-Original-To: mpls-interop@core3.amsl.com
Delivered-To: mpls-interop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756F33A69FC for <mpls-interop@core3.amsl.com>; Mon, 4 May 2009 11:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.982
X-Spam-Level:
X-Spam-Status: No, score=-3.982 tagged_above=-999 required=5 tests=[AWL=-1.733, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 eJizSJx+eYs8 for <mpls-interop@core3.amsl.com>; Mon, 4 May 2009 11:57:38 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id C5F883A68A0 for <mpls-interop@ietf.org>; Mon, 4 May 2009 11:57:36 -0700 (PDT)
Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n44Iwwjw020353; Mon, 4 May 2009 20:58:58 +0200
Received: from [135.244.33.75] ([135.244.33.75]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 20:58:57 +0200
Message-ID: <49FF3AE6.6010200@alcatel-lucent.com>
Date: Mon, 04 May 2009 20:58:46 +0200
From: Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Malcolm Betts <betts01@nortel.com>
References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <0BDFFF51DC89434FA33F8B37FCE363D516FDB211@zcarhxm2.corp.nortel.com> <49FEE492.2070609@alcatel-lucent.com> <0BDFFF51DC89434FA33F8B37FCE363D517037DDC@zcarhxm2.corp.nortel.com>
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D517037DDC@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 04 May 2009 18:58:58.0283 (UTC) FILETIME=[6140F3B0:01C9CCEA]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Cc: mpls-interop@ietf.org
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock
X-BeenThere: mpls-interop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF MPLS Interoperability Design Team <mpls-interop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-interop>, <mailto:mpls-interop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-interop>
List-Post: <mailto:mpls-interop@ietf.org>
List-Help: <mailto:mpls-interop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-interop>, <mailto:mpls-interop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2009 18:57:39 -0000

Malcolm,

it appears that we agree on the need for the two functionalities:
- notification to the receiving end point of lock having been
   performed at the source point.
- request from an end point that the other far end performs a lock.

What I do not understand is why do you want to force the piggybacking
of the latter on the former.
We should stick to required elementary functionalities and not impose
a given protocol implementation.

regards,
martin

Malcolm Betts a écrit :
> Martin,
> 
> I am tempted to simplify still further, just notify the far end that the lock is in place and allow the decision to lock the reverse direction to be a locally configured option.
> 
> I cannot think of a case where you would only want to lock one direction of a bidirectional LSP, so this would be the default behaviour.
> 
> 
> Malcolm Betts
> Nortel Networks
> Phone: +1 613 763 7860 (ESN 393)
> email: betts01@nortel.com
> 
> -----Original Message-----
> From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] 
> Sent: Monday, May 04, 2009 8:50 AM
> To: Betts, Malcolm (CAR:X632)
> Cc: Adrian Farrel; mpls-interop@ietf.org
> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock
> 
> Malcolm,
> 
> I fully agree that the lock is performed locally.
> I also agree that the other end point must be aware of this lock.
> This is exactly what I have written below.
> 
> On bidir LSP the notification may be used to request the lock at the far end but this is for me an implementation decision.
> We should, as agreed during the call, stick to elementary functionalities.
> Therefore we need two distinct functionalities:
> inform the far end that lock has been performed request the far end to perform lock
> 
> do we agree on that?
> 
> one functionality I believe we also need is to inform client layers of the lock condition of a server, but I'll discuss this in the other e-mail you sent.
> 
> regards,
> -m
> 
> Malcolm Betts a écrit :
>> Martin,
>>
>> The key point is that the lock action is implemented locally.  e.g. at the sending end of a LSP the traffic can be blocked.  One example of the use of this is to allow a test source to be connected (vs. client traffic).  Even on a unidirectional LSP it is useful to have a notification sent to the receiving end of the LSP so that it is aware that it is not receiving "valid" client traffic.
>>
>> On a bidirectional LSP this notification may be used to activate a lock in the reverse direction.
>>
>> Hope this clears up the confusion.
>>  
>>
>>
>> Malcolm Betts
>> Nortel Networks
>> Phone: +1 613 763 7860 (ESN 393)
>> email: betts01@nortel.com
>>
>> -----Original Message-----
>> From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com]
>> Sent: Sunday, May 03, 2009 2:22 PM
>> To: Adrian Farrel; Betts, Malcolm (CAR:X632)
>> Cc: mpls-interop@ietf.org
>> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and 
>> notification of lock
>>
>> Adrian, Malcolm, all,
>>
>> here are my thoughts on this:
>>
>> As far as I understand, strictly speaking the Lock function does not make sense on a unidir LSP. Indeed locking is performed at the source point and so there is no need to send any message to perform that Lock. (the potentially needed message is to inform the end-point(s) of the status but that is lock notification.
>> I'll come back to this).
>> Therefore Lock is only needed on a bidir entity and what is exactly needed is the capability to request the other end point to admin lock its direction.
>>
>> Coming back to the notification, I believe the following requirement is needed:
>>     The MPLS-TP OAM toolset MUST provide a functionality to enable an
>>     End Point of a PW, LSP or Section to inform the End Point(s) of that
>>     LSP, PW, or Section that the PW, LSP or Section has been
>>     administratively shutdown at this End Point.
>> But it is conditionally needed. This function is *only* needed if locking is achieved via Lock, otherwise if it is achieved via NMS commands we (I hope) can safely assume that:
>> for undir LSP there will be commands at both ends, one saying lock, the other saying you are notified of other end locking.
>> for bidir LSP there will be commands at both ends, both saying lock and you are notified of other end locking.
>>
>> The MUST is needed because the egress must be aware of the Lock because we expect him to then inform client MEPs that are "downstream". (see question at the end of this e-mail).
>>
>> The small problem I have is that this function is a notification one 
>> but really tightly linked to the Lock. In other words, I do not know 
>> where this reqs better fits (especially wrt to the conditional
>> issue): in Lock or in Lock Notification?
>> Opinions are welcomed.
>>
>> Therefore I propose:
>>
>> 2.2.x.  Lock
>> The MPLS-TP OAM toolset SHOULD provide a functionality to enable an End Point of a bidirectional PW, LSP or Section to request to its associated End Point that it administratively shuts down the direction of the PW, LSP or Section for which it is the head-end.
>>
>> This function SHOULD be performed on-demand.
>>
>> This function SHOULD be performed between the End Points of a PW, LSP or Section.
>>
>> Note that administratively shutting down corresponds to stopping user traffic being sent on the PW, LSP or Section.
>>
>>
>> 2.2.y.  Lock Notification
>> The MPLS-TP OAM toolset MUST provide a function to enable End Points 
>> of a (server) LSP or Section to notify, of its administrative locking 
>> status, the End Points of (client) PWs or LSPs affected by this status.
>>
>> This function SHOULD be performed on-demand.
>>
>> This function SHOULD be performed between the End Points of a PW, LSP 
>> or Section.
>> -comment:
>> this needs to be rephrased as the notifying end points may not be the 
>> same nodes than the notified end points.
>> The general case is in fact a notification between end points of 
>> different e.g., LSPs while the sentence seems to say that it is 
>> between the end-points of the same e.g., LSP.
>> Any suggestion welcomed.
>>
>> See also my e-mail:
>> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" 
>> OAM messages ?
>>
>> -question:
>> More generally to the comment above, who should notify and who should 
>> notify whom?
>> I would tend to say:
>> the receiving node of a locked direction, informs downstream receiving 
>> nodes of nested LSPs. This is a Fowrward Indication and if we do so 
>> then receiving points MUST indeed be informed of a Lock (c.f.
>> discussion at the beginning of the e-mail).
>> Should source points (locking points) do some reverse indication and 
>> notify the source points of the LSPs that are nested in the locked LSP?
>> (but this maybe falls in the RDI functionality).
>>
>> I guess that is all, sorry for this long e-mail.
>>
>> regards,
>> -m
>>
>>
>> Adrian Farrel a écrit :
>>> Hi Malcolm,
>>>
>>>> To address the comments from Adrian I suggest the following text for 
>>>> sections 2.2.7 and 2.2.8:
>>>>
>>>> Note that this proposal assumes that the text related to 
>>>> local/remote faults is moved from section 2.2.8 to section 2.2.2 as 
>>>> proposed in my previous email.
>>>>
>>>> We probably need to discuss this text on the MEAD team call next 
>>>> week.
>>>>
>>>> 2.2.7.  Lock
>>>>
>>>> The OAM toolset SHOULD provide a function enabling a network 
>>>> operator to administratively shut down a PW, LSP or Section; that 
>>>> is, to stop user traffic being sent over that PW, LSP or Section.
>>> This is great.
>>> Does it mean that we do not need to add the (similar) text on CV 
>>> fault behavior in section 2.2.3?
>>> It would seem so.
>>>
>>>> The lock function MAY be applied to a unidirectional or a 
>>>> bidirectional PW, LSP or Section.  If the lock function is activated 
>>>> at the head end of one direction of a bidirectional PW, LSP or 
>>>> Section then it SHOULD be possible to cause the lock function to be 
>>>> activated at the head end of the other direction.
>>>>
>>>> This function SHOULD be performed on-demand i.e. in response to an 
>>>> operator command.
>>> Or also in response to configured automatic behavior?
>>>
>>> But this is not a protocol requirement.
>>>
>>>> This function SHOULD be performed between End Points of PWs, LSPs 
>>>> and Sections.
>>>>
>>>> 2.2.8 Notification of Lock
>>>>
>>>> If the lock function is supported the MPLS-TP OAM toolset MUST 
>>>> provide a function to enable the End Point at the ingress to notify 
>>>> the End Points at the egress that the lock function is active.  This 
>>>> function SHOULD be performed pro-actively.
>>>>
>>>> The MPLS-TP OAM toolset MUST allow for the distinction between a 
>>>> fault condition and an administrative locking action.
>>> Works for me.
>>>
>>> A
>>>
>>>
>>>
>>> _______________________________________________
>>> Mpls-interop mailing list
>>> Mpls-interop@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls-interop
>>>
>