Re: [mpls-tp] Linera Protection

Mahesh, hi

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

Hope this helps,

Yaacov Weingarten

Nokia Siemens Networks

________________________________

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
Behalf Of ext Mahesh Akula
Sent: Monday, June 14, 2010 10:49
To: Adrian Farrel
Cc: mpls-tp@ietf.org; Mukund Mani
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.

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

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

[yw>] That is correct

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

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

Can someone please confirm on this?

Thanks,

Mahesh

On Sat, Jun 12, 2010 at 12:31 AM, Adrian Farrel <adrian@olddog.co.uk>
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" <gregimirsky@gmail.com>
To: "Shahram Davari" <davari@broadcom.com>
Cc: "Mukund Mani" <mukund.mani@gmail.com>om>; <mpls-tp@ietf.org>
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
<davari@broadcom.com>wrote;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:gregimirsky@gmail.com]
*Sent:* Friday, June 11, 2010 11:18 AM
*To:* Shahram Davari
*Cc:* Mach Chen; Mukund Mani; mpls-tp@ietf.org

*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 <davari@broadcom.com>
wrote:

Hi,

Why would one need to run more than one BFD session over an LSP?

Thanks,
Shahram

-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
Behalf
Of Mach Chen
Sent: Friday, June 11, 2010 3:05 AM
To: Mukund Mani; mpls-tp@ietf.org
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" <mukund.mani@gmail.com>
Sent: Friday, June 11, 2010 2:24 PM
To: <mpls-tp@ietf.org>
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
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

------------------------------------------------------------------------
-------- 

_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

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