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

From: Mahesh Akula <[email-masked]>
Date: Mon, 14 Jun 2010 11:23:35 -0700

Jeong-dong and All,

On Mon, Jun 14, 2010 at 2:05 AM, Ryoo, Jeong-dong <[email-masked]> 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: +82-42-860-5384, Fax: +82-42-860-6342
> Email: [email-masked]
> ==============================================
>
> -----Original Message-----
> *From:* "Mahesh Akula" <[email-masked]>
> *From Date:* 2010-06-14 PM 4:49:12
> *To:* "Adrian Farrel" <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>, "Mukund Mani" <
> [email-masked]>
> *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 <[email-masked]>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" <[email-masked]>
>> To: "Shahram Davari" <[email-masked]>
>> Cc: "Mukund Mani" <[email-masked]>; <[email-masked]>
>> 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 <[email-masked]
>>> >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:[email-masked]]
>>>> *Sent:* Friday, June 11, 2010 11:18 AM
>>>> *To:* Shahram Davari
>>>> *Cc:* Mach Chen; Mukund Mani; [email-masked]
>>>>
>>>> *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 <[email-masked]>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Why would one need to run more than one BFD session over an LSP?
>>>>
>>>> Thanks,
>>>> Shahram
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf
>>>> Of Mach Chen
>>>> Sent: Friday, June 11, 2010 3:05 AM
>>>> To: Mukund Mani; [email-masked]
>>>> 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" <[email-masked]>
>>>> Sent: Friday, June 11, 2010 2:24 PM
>>>> To: <[email-masked]>
>>>> 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
>>>> > [email-masked]
>>>> > https://www.ietf.org/mailman/listinfo/mpls-tp
>>>> >
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>
>>>>
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>>
>> _______________________________________________
>>> mpls-tp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>
>>>
>> _______________________________________________
>> mpls-tp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
>
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>

---

From: 류정동 <[email-masked]>
Date: Tue, 15 Jun 2010 12:02:15 +0900

Mahesh,

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

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.

Jeong-dong

-----원본 메시지-----
From: "Mahesh Akula" <[email-masked]>
From Date: 2010-06-15 오전 3:23:35
To: "Ryoo, Jeong-dong" <[email-masked]>, "[email-masked]" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mpls-tp] Linera Protection - Operator commands terminology.

Jeong-dong and All,

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

?

?

-----Original Message-----
From: "Mahesh Akula" <[email-masked]>
From Date: 2010-06-14 PM 4:49:12
To: "Adrian Farrel" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Mukund Mani" <[email-masked]>
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"?

?

?

?? 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.

?

?

Thanks,

Mahesh

?

On Sat, Jun 12, 2010 at 12:31 AM, Adrian Farrel <[email-masked]> 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

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 <[email-masked]>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

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

Hi,

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mach Chen
Sent: Friday, June 11, 2010 3:05 AM
To: Mukund Mani; [email-masked]
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Hi Mukund,

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

> "When using BFD over MPLS-TP LSPs, the BFD discriminator MUST either be
BFD
discriminator
> values are not required for demultiplexing to the BFD session anymore, > we
> 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

---

From: Mahesh Akula <[email-masked]>
Date: Mon, 14 Jun 2010 21:29:58 -0700

Hello Jeong-dong,

2010/6/14 류정동 <[email-masked]>

> 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?

> The priority values for FS and SF-P and the detailed operation are

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

> *From Date:* 2010-06-15 오전 3:23:35
> *To:* "Ryoo, Jeong-dong" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "Adrian Farrel" <[email-masked]>
>
> *Cc:* "[email-masked]" <[email-masked]>
> *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 <[email-masked]>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.
>>
>
> ?"If the protection domain is currently in a protecting state, then the
>> 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.
>> ?
>> 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.
>> ?

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Tue, 15 Jun 2010 14:56:23 +0900

Mahesh,

I believe your statements are now alll aligned with my understanding.

I cannot say much about the draft-ietf-mpls-tp-linear-protection draft, which has different concepts than existing APS based linear protection.

All of my understanding and statements are based on APS based linear protection, which is realized in another draft, draft-zulr-mpls-tp-linear-protection-switching, for MPLS-TP protection.

I believe that MPLS-TP linear protection switching should be fast and its protocol should not have any potential problems.

In this sense, the APS based linear protection is more suitable for MPLS-TP protection.

Best regards,

Jeong-dong

-----Original Message-----
From: "Mahesh Akula" <[email-masked]>
From Date: 2010-06-15 PM 1:29:58
To: 류정동 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Re: [mpls-tp] Linera Protection - Operator commands terminology.

Hello Jeong-dong,

Mahesh,

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?

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

-----원본 메시지-----

Jeong-dong and All,

Mahesh,

?

?

?

?

Jeong-dong

Regards,
Mahesh

?

?

-----Original Message-----
From: "Mahesh Akula" <[email-masked]>
From Date: 2010-06-14 PM 4:49:12
To: "Adrian Farrel" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Mukund Mani" <[email-masked]>
Subject: [mpls-tp] Linera Protection - Operator commands terminology.

Hello All,

?

?

?

?

?

?

?

?

Thanks,

Mahesh

?

Greg'n'Shahram,

cheers,
Adrian

Hi Shahram,

Regards,
Greg

?Hi Greg,

Regards,

Shahram

Dear Shahram,

Regards,
Greg

Hi,

Thanks,
Shahram

-----Original Message-----

Hi Mukund,

Best regards,
Mach

BFD
discriminator

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Tue, 15 Jun 2010 23:21:57 +0900

My previous message exceeds the limit, and I am sending it again after truncating the end.

-----Original Message-----
From: "류정동" <[email-masked]>
From Date: 2010-06-15 PM 11:18:30
To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>, "ext Mahesh Akula" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: "Mukund Mani" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Re: [mpls-tp] Linera Protection - Operator commands terminology.

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

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

-----Original Message-----
From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
From Date: 2010-06-15 PM 8:34:00
To: "ext Mahesh Akula" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: "Mukund Mani" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mpls-tp] Linera Protection - Operator commands terminology.

Mahesh, hi

Thank you for your comments, my answers are included below.

Hope this helps,

Yaacov Weingarten

Nokia Siemens Networks

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Mahesh Akula
Sent: Monday, June 14, 2010 10:49
To: Adrian Farrel
Cc: [email-masked]; Mukund Mani
Subject: [mpls-tp] Linera Protection - Operator commands terminology.

Hello All,

[yw>] The actions taken by the two operator commands are very similar, the main difference between them is in the priority/urgency that they demand.  A Forced Switch should take effect in spite of any signal failure condition of the recovery path, whereas the Manual Switch is used to invoke the protection switch only if there are no signal failure conditions present in the protection domain.

[yw>] That is correct

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

[yw>] This coincides with my previous comment

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?

[yw>] Yes, this is correct

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.

[yw>] I am not sure that all of the state transition definitions of G.8031 are relevant to MPLS-TP although we are trying to define the linear-protection to act close to that of Ethernet (the target environment of G.8031).  Regarding the "down" state of the recovery entity - There is a need to differentiate between the two possible reasons for the recovery entity to be down ? if the down state is the result of a Lockout command, then even a Forced Switch cannot overcome this.  If the "down" state is the result of a SF-P condition, then the Forced Switch should be able to take effect.

Thanks,

Mahesh

---

From: Mahesh Akula <[email-masked]>
Date: Tue, 15 Jun 2010 15:54:37 -0700

> 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 <[email-masked]>wrote:
>
>>  Yaacov,
>>
>> In my opinion, if there is any technical problem in the
>> mechanism/protocol, the problem should be solved.
>>
>> 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.
>>
>> *From:* "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <
>> [email-masked]>
>> *From Date:* 2010-06-15 PM 10:52:21
>> *To:* "Ryoo, Jeong-dong" <[email-masked]>, "ext Mahesh Akula" <
>> [email-masked]>, "Adrian Farrel" <[email-masked]>
>> *Cc:* "Mukund Mani" <[email-masked]>, "[email-masked]" <
>> [email-masked]>
>>  *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:[email-masked]]
>> *Sent:* Tuesday, June 15, 2010 16:38
>> *To:* Weingarten, Yaacov (NSN - IL/Hod HaSharon); ext Mahesh Akula;
>> Adrian Farrel
>> *Cc:* Mukund Mani; [email-masked]
>> *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.
>>

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Wed, 16 Jun 2010 18:39:51 +0900

Yaacov,

I am not redefining either requirement or architecture.

The terminology used in draft-ietf-mpls-tp-survive-fwk is consistent with RFC4427 which is also consistent with G.808.1. (see section 2). And, the draft-ietf-mpls-tp-survive-fwk has both RFC4427 and G.808.1 as normative references.

RFC4427 also refers to G.808.1.

G.808.1 again refers to G.870 for the definition of FS, and in section 3.2.29 of G.870, it is clearly stated that SF on protection transport entity (over which the APS signal is routed) has priority over the forced switch.

So, all the documents, such as draft-ietf-mpls-tp-survive-fwk, RFC4427, G.808.1, G.870 and G.8031, are all aligned for the definition of FS, and further the relationship with SF-P.

The mismatch scenario that I stated in my earlier emails is a technical reason why they did that way.

There still is a difference between MS and FS.

Instead of repeating the definitions written in draft-ietf-mpls-tp-survive-fwk and other docuemnts, let me give you an example:

When a node/link should be replaced in working path, FS can be issued to avoid the alram (SF)  to a management system.
MS cannot do the job in this example.

Jeong-dong

-----Original Message-----
From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
From Date: 2010-06-16 PM 5:25:53
To: "Ryoo, Jeong-dong" <[email-masked]>, "ext Mahesh Akula" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: "Mukund Mani" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Re: [mpls-tp] Linera Protection - Operator commands terminology.

Jeong-dong, hi

I fully agree with you regarding solving technical problems, although it would be better to design the system so that there are no technical problems.

However, the problem that I was pointing out is that you are redefining the requirements to fit your architecture (i.e. according to this design there is no real operational difference between FS and MS) rather than trying to redesign the architecture to fit the requirements.  I have a feeling (but this is a personal opinion) that the architecture was correct for SDH/SONET, but less applicable to the packet-network world ? but you need to preserve the architecture!

Regards,

yaacov

Sent: Tuesday, June 15, 2010 17:19

Yaacov,

Jeong-dong

-----Original Message-----
From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
From Date: 2010-06-15 PM 10:52:21
To: "Ryoo, Jeong-dong" <[email-masked]>, "ext Mahesh Akula" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: "Mukund Mani" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Re: [mpls-tp] Linera Protection - Operator commands terminology.

Hi,

BR,

yaacov

Yaacov,

What do you think?

Jeong-dong

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Wed, 16 Jun 2010 19:24:40 +0900

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

-----Original Message-----
From: "Mahesh Akula" <[email-masked]>
From Date: 2010-06-16 AM 7:54:37
To: "Ryoo, Jeong-dong" <[email-masked]>
Cc: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>, "[email-masked]" <[email-masked]>
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.

?

?

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 <[email-masked]> 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

?

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

?

?

-----Original Message-----

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

?

?

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.

?

What do you think?

?

Jeong-dong?

?

---

From: Mahesh Akula <[email-masked]>
Date: Wed, 16 Jun 2010 12:19:43 -0700

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 <[email-masked]> 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.
>
> *From Date:* 2010-06-16 AM 7:54:37
> *To:* "Ryoo, Jeong-dong" <[email-masked]>
> *Cc:* "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject:* Re: Re: [mpls-tp] Linera Protection - Operator commands
> terminology.
>
>
>  Hello Jeong-dong,
>> ?
>> 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
>> 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
>>
>>> mechanism/protocol,?the problem should be solved.
>>> ?
>>> 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.
>>> ?
>>> differentiation between the FS and MS commands!? The idea of the difference
>>> 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
>>> 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