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

[Mahesh Akula <[e-mail]>]

Jeong-dong and All,

On Mon, Jun 14, 2010 at 2:05 AM, Ryoo, Jeong-dong <[e-mail]> wrote:

> Mahesh,
>
> As per the Manual Switch (MS) command,  an operator can send normal traffic
> to either the protection path or the working path when there is no defect in
> any of the paths.
>

> MS to protection (MS in G.8031) is to send normal traffic to the protection
> entity
> (same as "Manual switch-over for normal traffic" in RFC4427) and
> MS to working is (MS-W in G.8031) to send the traffic to the working entity
>
> (same as "Manual switch-over for recovery LSP/span" in RFC4427).
>

Mahesh:- As per draft-ietf-mpls-tp-linear-protection-01 draft,
 "If the protection domain is currently in a protecting state, then the
LSR's should NOT accept a Manual Switch Request."

With respect to this statement, only definition for the MS to protection
will be applicable in MPLS-TP right? Anyways this should n't be a problem
because "Clear" operator command can be used to switch back to working from
recovery, thus we probably don't need MS-W. I guess
draft-ietf-mpls-tp-linear-protection-01 should explicitly state this instead
of referring to RFC 4427 in my opinion.

>
>
> The operation you described for Forced Switch (FS) in G.8031 (or
> draft-zulr-mpls-tp-linear-protection-switching)
> is a correct observation, as Signal Fail on protection (SF-P) has higher
> priority than FS.
>
> When there is SF-P, the normal traffic should be selected from the working
> entity and FS request should not be honoured.
> As any APS message, FS in this case, cannot be delivered to the other end
> during SF-P condition,
> it is dangerous to make the priority of FS be higher than SF-P.
>

Mahesh: So survivability framework needs to be updated to provide different
definitions for MS and FS i suppose. Because with the current definitions it
gives meaning that FS can be triggered even when the recovery entity is in
defect state.

>
> Jeong-dong
>

Regards,
Mahesh

>
>
>     ==============================================
> 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:* "Mahesh Akula" <[e-mail]>
> *From Date:* 2010-06-14 PM 4:49:12
> *To:* "Adrian Farrel" <[e-mail]>
> *Cc:* "[e-mail]" <[e-mail]>rg>, "Mukund Mani" <
> [e-mail]>
> *Subject:* [mpls-tp] Linera Protection - Operator commands terminology.
>
> Hello All,
> ?
> I'm little confused related to what should be the behavior of Manual/Forced
> switch operator commands related to protection switching. It will be really
> helpful if someone can summarize what should be the difference between these
> operator commands.
> ?
> draft-ietf-mpls-tp-linear-protection-01 refers to RFC 4427 for the
> definitions. But RFC 4427 has two definitions for Manual switchover. Manual
> switch-over for normal traffic and Manual switch-over for recovery LSP/span.
> Am i supposed to assume here that Manual switch-over refers to "Manual
> switch-over for normal traffic"?
> ?
> Also, as per the survavibility-fwk I could see these definitions:-
> ?
> ?? o? Force protection action - a manual command that forces a switch of?
> normal data traffic to the recovery entity
>
> ?? o? Manual protection action - a manual command that forces a switch of
> data traffic to the recovery entity only when there is no
> ????? defect in the recovery entity
> ?
> From these?definitions I would take that "Forced switch" will switch to
> the?recovery entity?from the working entity, eventhough the recovery
> entity?is in?defect state.?Is this right?
> ?
> I could find some extensive?state transition diagrams?related to protection
> switching in G.8031(Not sure if i'm supposed to refer this),?as per this
> state transition diagrams when the recovery entity is down even the Forced
> switchover action is not allowed to switch from the working to recovery
> entity.
> ?
> Can someone please confirm on this?
> ?
> Thanks,
> Mahesh
>
> ?
> On Sat, Jun 12, 2010 at 12:31 AM, Adrian Farrel <[e-mail]>wrote;wrote:
>
>> Greg'n'Shahram,
>>
>> Please do check the terminology with the Survivability Framework.
>> It is (just) not too late to tweak if we have got something wrong or left
>> something out.
>>
>> cheers,
>> Adrian
>> ----- Original Message ----- From: "Greg Mirsky" <[e-mail]>
>> To: "Shahram Davari" <[e-mail]>
>> Cc: "Mukund Mani" <[e-mail]>om>; <[e-mail]>
>> Sent: Friday, June 11, 2010 8:02 PM
>>
>> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>>
>>
>> Hi Shahram,
>>> yes, we need to settle on terminology related to protection.
>>> It was discussed and presented at the last IETF meeting how
>>> bi-directional
>>> BFD session easily can operate in, effectively, unidirectional mode. I
>>> think
>>> that operating BFD session in this mode is applicable to unidirectional
>>> and
>>> associated bi-directional p2p LSPs.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Fri, Jun 11, 2010 at 11:54 AM, Shahram Davari <[e-mail]
>>> >wrote:
>>>
>>> ?Hi Greg,
>>>>
>>>>
>>>>
>>>> I assume by independent protection mode you mean unidirectional
>>>> protection.
>>>> If unidirectional protection is required, then it is simpler to not use
>>>> ?bidirectional BFD session.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Shahram
>>>>
>>>>
>>>>
>>>> *From:* Greg Mirsky [mailto:[e-mail]]
>>>> *Sent:* Friday, June 11, 2010 11:18 AM
>>>> *To:* Shahram Davari
>>>> *Cc:* Mach Chen; Mukund Mani; [e-mail]
>>>>
>>>> *Subject:* Re: [mpls-tp] Demultiplexing to BFD sessions
>>>>
>>>>
>>>>
>>>> Dear Shahram,
>>>> assume one BFD session is applied to an associated bi-directional LSP.
>>>> Then
>>>> failure in one direction will bring the session in Down state which is
>>>> not
>>>> desired behavior for independent protection mode. Thus, I think, need
>>>> for
>>>> two BFD, in essence unidirectional, sessions.
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Fri, Jun 11, 2010 at 11:03 AM, Shahram Davari <[e-mail]>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Why would one need to run more than one BFD session over an LSP?
>>>>
>>>> Thanks,
>>>> Shahram
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf
>>>> Of Mach Chen
>>>> Sent: Friday, June 11, 2010 3:05 AM
>>>> To: Mukund Mani; [e-mail]
>>>> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>>>>
>>>> Hi Mukund,
>>>>
>>>> I also have the same question about this.
>>>>
>>>> As to the BFD discriminator, IMHO, we should keep using it as it be,
>>>> because
>>>> it may not be enough to demultiplex the BFD session only based on the
>>>> label,
>>>> this is especially true when there are more than two BFD sessions over
>>>> the
>>>> LSP.
>>>>
>>>> BTW, it seems that explicit null label distribution is not excluded (and
>>>> IMHO it should be excluded as PHP) in MPLS-TP (do I miss something?) ,
>>>> and
>>>> it is one of the issues that LSP-Ping for BFD session bootstrap is
>>>> trying
>>>> to
>>>> reslove.
>>>>
>>>> Best regards,
>>>> Mach
>>>>
>>>> --------------------------------------------------
>>>> From: "Mukund Mani" <[e-mail]>
>>>> Sent: Friday, June 11, 2010 2:24 PM
>>>> To: <[e-mail]>
>>>> Subject: [mpls-tp] Demultiplexing to BFD sessions
>>>>
>>>> > Hi TP-Group
>>>> > **
>>>> > *draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 *states in Section 3
>>>> >
>>>> > "When using BFD over MPLS-TP LSPs, the BFD discriminator MUST either
>>>> be
>>>> > signaled via LSP-Ping or be statically configured."
>>>> >
>>>> > *draft-ietf-mpls-tp-bfd-cc-cv-00 *states in Section 3.5.6
>>>> >
>>>> > "MPLS labels at peer MEPs are used to provide context for the received
>>>> BFD
>>>> > packets."
>>>> >
>>>> > As I understand from the statement in the CC/CV draft, since
>>>> discriminator
>>>> > values are not required for demultiplexing to the BFD session anymore,
>>>> > we
>>>> > will not need LSP Ping to bootstrap BFD session for TP LSP.
>>>> >
>>>> > But *draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 *specifies that LSP
>>>> > Ping
>>>> > can also be used to signal BFD discriminator.
>>>> >
>>>> > So is LSP Ping still really needed in the context of BFD over MPLS-TP?
>>>> >
>>>> > Also as a part of MPLS-TP OAM could somebody explain why such a >
>>>> deviation
>>>> > is
>>>> > taken from the BFD-BASE mode of demultiplexing which even BFD-MPLS
>>>> uses
>>>> > (discriminator values instead of MPLS labels), but MPLS-TP goes in for
>>>> > demultiplexing using labels....
>>>> >
>>>> > Could somebody please clarify this..?
>>>> >
>>>> >
>>>> > With Regards
>>>> > Mukund
>>>> > <http://tools.ietf.org/html/draft-ietf-mpls-tp-bfd-cc-cv-00>
>>>> >
>>>>
>>>>
>>>>
>>>> > _______________________________________________
>>>> > mpls-tp mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/mpls-tp
>>>> >
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>
>>>>
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>>
>> _______________________________________________
>>> mpls-tp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>
>>>
>> _______________________________________________
>> mpls-tp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
>
>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>