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

[Mahesh Akula <[e-mail]>]

Hello Jeong-dong,

2010/6/14 류정동 <[e-mail]>

>  Mahesh,
>
> MS to working can be used in DNR state for non-revertive mode, or even in
> WTR state for for revertive mode.
>

Then the statement in linear protection draft that MS should not be accepted
when the protection domain is in protection statement need to be modified
then?

>
> Well, I am not sure that the survivability framework should be updated.
> In my opinion, the survivability framework presents general high-level
> architectures.
> The priority values for FS and SF-P and the detailed operation are
> technology-specific.
>

Linear protection draft defines the prorities for different requests
including FS and SF. It does not explicitly mentions the SF-P, but it gives
FS highert priority than SF in generic. Pls correct me if i'm missing out
anything.

Regads,
Mahesh

>  Jeong-dong
>
>
>
> -----원본 메시지-----
>
> *From:* "Mahesh Akula" <[e-mail]>
> *From Date:* 2010-06-15 오전 3:23:35
> *To:* "Ryoo, Jeong-dong" <[e-mail]>kr>, "[e-mail]" <
> [e-mail]>gt;, "Adrian Farrel" <[e-mail]>
>
> *Cc:* "[e-mail]" <[e-mail]>
> *Subject:* Re: [mpls-tp] Linera Protection - Operator commands
> terminology.
>
> Jeong-dong and All,
>
>   On Mon, Jun 14, 2010 at 2:05 AM, Ryoo, Jeong-dong <[e-mail]>wrote;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
>>
>>
>