Re: [mpls-tp] Demultiplexing to BFD sessions

[Greg Mirsky <[e-mail]>]

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