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

[Mahesh Akula <[e-mail]>]

> 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 <[e-mail]>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: [phone], Fax: [phone]
>> Email: [e-mail]
>> ==============================================
>>
>> -----Original Message-----
>> *From:* "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <
>> [e-mail]>
>> *From Date:* 2010-06-15 PM 10:52:21
>> *To:* "Ryoo, Jeong-dong" <[e-mail]>kr>, "ext Mahesh Akula" <
>> [e-mail]>gt;, "Adrian Farrel" <[e-mail]>
>> *Cc:* "Mukund Mani" <[e-mail]>om>, "[e-mail]" <
>> [e-mail]>
>>  *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:[e-mail]]
>> *Sent:* Tuesday, June 15, 2010 16:38
>> *To:* Weingarten, Yaacov (NSN - IL/Hod HaSharon); ext Mahesh Akula;
>> Adrian Farrel
>> *Cc:* Mukund Mani; [e-mail]
>> *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: [phone], Fax: [phone]
>> Email: [e-mail]
>> ==============================================
>>
>