Re: [mpls-tp] Linera Protection - Operator commands terminology.

Mahesh Akula <mahesh.akula36@gmail.com> Wed, 16 June 2010 19:19 UTC

Return-Path: <mahesh.akula36@gmail.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838943A6BAB for <mpls-tp@core3.amsl.com>; Wed, 16 Jun 2010 12:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6]
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 0aqn5oloVjrI for <mpls-tp@core3.amsl.com>; Wed, 16 Jun 2010 12:19:49 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id B1A943A6BAA for <mpls-tp@ietf.org>; Wed, 16 Jun 2010 12:19:41 -0700 (PDT)
Received: by pvc30 with SMTP id 30so425369pvc.31 for <mpls-tp@ietf.org>; Wed, 16 Jun 2010 12:19:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=D9AsHdu3tTVQY4jWnMBuhWkuS5MOurPYoRiqPjcQlRM=; b=mW/dy4tusPBDGK1EG0MX/E/1E8hXAgAolup5wtep1B03F5QTmpw/OyNCgEuJQZFr4K h5QJLyNUhrjLj/EMDzfKBu1UXvIBDoy76PcVPm7Z/3Kh7QG9X8uTnmUWliZKQna/49eb hKhwzcRFpmqcsSyNorY32EGQE6zB7FlDhYeO4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ISwJu/o3Mw/cm38M0jIjtYe8YjKLDV5XbvLWlUbi29dWUEcKoavp4/bJ1o4CQqbXc/ Mu6K6vyMjqyb9jjWbglkPUX0ZI5m58rXzX1BCFa0X4Vt85rNz5TzzDgBgZcTFqomLmgC +GyZShNyyP9A0djLmOCh0smV8duB3NnaIbJvc=
MIME-Version: 1.0
Received: by 10.143.25.2 with SMTP id c2mr6541387wfj.147.1276715983460; Wed, 16 Jun 2010 12:19:43 -0700 (PDT)
Received: by 10.142.102.19 with HTTP; Wed, 16 Jun 2010 12:19:43 -0700 (PDT)
In-Reply-To: <D24353715A854C7280A5707C8CA9C933@etri.info>
References: <D24353715A854C7280A5707C8CA9C933@etri.info>
Date: Wed, 16 Jun 2010 12:19:43 -0700
Message-ID: <AANLkTin3fRsfGWnC53qNzU8zLlZ-BBlZPjITM3pMY05P@mail.gmail.com>
From: Mahesh Akula <mahesh.akula36@gmail.com>
To: "Ryoo, Jeong-dong" <ryoo@etri.re.kr>
Content-Type: multipart/alternative; boundary=001636e1f81bac5b1504892a9aa7
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Linera Protection - Operator commands terminology.
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2010 19:19:51 -0000

Hi Jeong-dong,

Thanks, yes it does clarify the usage of those commands to me.

Regards,
Mahesh

On Wed, Jun 16, 2010 at 3:24 AM, Ryoo, Jeong-dong <ryoo@etri.re.kr> wrote:

> Hi, Mahesh.
>
> Everything you said is ok, except the fact MS is to move the normal traffic
> to the protection path, and MS-W is to move the traffic to the working
> path.FS is to move the traffic to the protection path.
>
> When an operator issues the FS command and removes a node/link in the
> working path, there would be no SF report to the operator or its management
> system. This says that something happening in the working path is due to the
> intentional act of the operator, not by the defect in the working path.
>
> During MS state, if a node/link is removed in the working path, SF will
> occur and the traffic goes to the protection path.
>
> MS-W is for moving the traffic to the working path, and it can be used in
> DNR state or WTR state.
> I hope this can clarify the definition/usage of those commands.
>
> Jeong-dong
>
>     ==============================================
> Jeong-dong Ryoo, Ph.D.
> Principal Member of Research Staff
> Network Research Department
> Electronics and Telecommunications Research Institute (ETRI)
> Phone: +82-42-860-5384, Fax: +82-42-860-6342
> Email: ryoo@etri.re.kr
> ==============================================
>
> -----Original Message-----
> *From:* "Mahesh Akula" <mahesh.akula36@gmail.com>
> *From Date:* 2010-06-16 AM 7:54:37
> *To:* "Ryoo, Jeong-dong" <ryoo@etri.re.kr>
> *Cc:* "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <
> yaacov.weingarten@nsn.com>gt;, "mpls-tp@ietf.org" <mpls-tp@ietf.org>
> *Subject:* Re: Re: [mpls-tp] Linera Protection - Operator commands
> terminology.
>
>
>  Hello Jeong-dong,
>> ?
>> After looking little more into the state transition diagrams in G.8031, I
>> could see the following difference between FS and MS-W.
>> ?
>> If Protection domain is in Forced Switch state, changes in the working
>> path (i.e. SF /SF recovery events) will have no impact on the protection
>> domain state, and recovery path is continued to be used as Active path,
>> unless the recovery path itself goes down or lockout protection/clear
>> commands are triggered.
>> ?
>> Whereas if protection domain is in Manual Switch state,?a series of SF and
>> SF recovery events on the working path will lead to switching the traffic
>> back from recovery path to Working path.
>> ?
>> Is this the expected difference between FS and MS operations?
>> ?
>> If this is not the case, can you pls clarify what is the difference
>> between FS and MS-W as per APS definitions? Also it will be helpful if you
>> can provide the?applicability for these operator commands.
>> ?
>> Regards,
>> Mahesh
>>
>>   On Tue, Jun 15, 2010 at 7:18 AM, Ryoo, Jeong-dong <ryoo@etri.re.kr>wrote;wrote:
>>
>>>  Yaacov,
>>> ?
>>> In my opinion, if there is any technical problem in the
>>> mechanism/protocol,?the problem should be solved.
>>> ?
>>> Besides, the mismatch problem that I stated in my previous?email is
>>> what?G.8031 already?avoids by assigning
>>> different priorities for SF-P and FS.
>>> ?
>>> In the MPLS-TP survivability framework document, the definition of FS
>>> does not have any?consideration on the?defect condition. And the definition
>>> of FS in the MPLS-TP survivability framework document is the SAME as that in
>>> G.8031.
>>> ?
>>> I don't think the behaviour that I stated?violates the architecture.
>>>  ?
>>> Jeong-dong
>>> ?
>>>
>>> ?
>>>     ==============================================
>>> Jeong-dong Ryoo, Ph.D.
>>> Principal Member of Research Staff
>>> Network Research Department
>>> Electronics and Telecommunications Research Institute (ETRI)
>>> Phone: +82-42-860-5384, Fax: +82-42-860-6342
>>> Email: ryoo@etri.re.kr
>>> ==============================================
>>>
>>> -----Original Message-----
>>> *From:* "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <
>>> yaacov.weingarten@nsn.com>
>>> *From Date:* 2010-06-15 PM 10:52:21
>>> *To:* "Ryoo, Jeong-dong" <ryoo@etri.re.kr>kr>, "ext Mahesh Akula" <
>>> mahesh.akula36@gmail.com>gt;, "Adrian Farrel" <adrian@olddog.co.uk>
>>> *Cc:* "Mukund Mani" <mukund.mani@gmail.com>om>, "mpls-tp@ietf.org" <
>>> mpls-tp@ietf.org>
>>>  *Subject:* RE: Re: [mpls-tp] Linera Protection - Operator commands
>>> terminology.
>>>
>>>    Hi,
>>>
>>> ?
>>>
>>> I think that this means that there is a conceptual problem with the
>>> differentiation between the FS and MS commands!? The idea of the difference
>>> that has always been explained is that FS would force a switchover even in
>>> the case of a signal failure ? if as you say that this is not possible
>>> because of the insufficiency of the architecture ? then there is a need to
>>> redesign the architecture or redefine the set of operator commands.
>>>
>>> ?
>>>
>>> BR,
>>>
>>> yaacov
>>>
>>> ?
>>>  ------------------------------
>>>
>>> *From:* ext Ryoo, Jeong-dong [mailto:ryoo@etri.re.kr]
>>> *Sent:* Tuesday, June 15, 2010 16:38
>>> *To:* Weingarten, Yaacov (NSN - IL/Hod HaSharon); ext Mahesh Akula;
>>> Adrian Farrel
>>> *Cc:* Mukund Mani; mpls-tp@ietf.org
>>> *Subject:* RE: Re: [mpls-tp] Linera Protection - Operator commands
>>> terminology.
>>>
>>> ?
>>>
>>> Yaacov,
>>>
>>> ?
>>>
>>> When there is SF on Protection (SF-P),?the Forced Switch (FS)?command
>>> cannot be delivered to?the other end as the APS/PSC protocol message is
>>> conveyed via the protection path.
>>>
>>> As the result, one end is in FS state?and points its selector/bridge to
>>> the protection path
>>>
>>> while?the other end is in SF-P state and points its selector/bridge to
>>> the working path.
>>>
>>> In order to avoid the mismatch, SF-P needs to have a higher priority than
>>> FS.
>>>
>>> ?
>>>
>>> What do you think?
>>>
>>> ?
>>>
>>> Jeong-dong?
>>>
>>>
>>> ?
>>>
>>> ==============================================
>>> Jeong-dong Ryoo, Ph.D.
>>> Principal Member of Research Staff
>>> Network Research Department
>>> Electronics and Telecommunications Research Institute (ETRI)
>>> Phone: +82-42-860-5384, Fax: +82-42-860-6342
>>> Email: ryoo@etri.re.kr
>>> ==============================================
>>>
>>