Re: [mpls-tp] Demultiplexing to BFD sessions

[Greg Mirsky <[e-mail]>]

Dear Lavanya,
I agree with your and Mach rationale on Explicit Null label in regard to
transport packet network. But we need to remember that the MPLS-TP defines
packet switching network. The profile of packet transport will be based on
subset of features defined in MPLS-TP and it might be the case that PHP will
be disabled for packet transport networks based on MPLS-TP.

Regards,
Greg

On Sun, Jun 13, 2010 at 12:00 PM, Lavanya Srivatsa <
[e-mail]> wrote:

> I am with Mach on both counts -
>
> (1) IMHO too, explicit null label distribution and PHP needs to be sorted
> out. If an OAM packet is received without the label, demultiplexing would
> become a problem. Even if the OAM packet contains discriminator values, if
> the packet does not carry the label, determining the LSP and therefore the
> destination MEP would be difficult in order to do CV (since only the source
> MEP TLV will be carried in the packet). Therefore I think the OAM context
> will be lost in case of PHP.
>
> BTW, can someone please clarify as to why the data plane draft introduces
> the "disabled by default" for PHP? I remember this point was raised by
> Curtis Villamizar earlier (Wed, 14 Apr 2010 ) but apart from someone
> suggesting that this gave the operator a choice, I dont seem to remember a
> concrete reason for this. IMHO, it should be "disabled at all times" for
> MPLS-TP networks.
>
> (2) Is there any draft which defines the "unidirectional " and
> "bidirectional" BFD sessions? I share Mach's confusion on this. Since the
> BFD state machine changes state based on what it receives from the peer node
> during session establishment, I think that a return path is necessary for
> the BFD session to be set up.
> Also, I am not sure why in order to perform unidirectional protection, a
> bidirectional BFD session need not/can not be used. I think even if we need
> to do unidirectional protection, all we need are the for 2 directions to
> operate independently, so that a fault in one direction of the path causes
> only that direction of the path to be moved on the protection/recovery path.
> So IMHO the number of sessions or unidirectional/bidirectional BFD sessions
> should be independent of the protection mechanism.
>
> - Lavanya
>
>
> Date: Sat, 12 Jun 2010 10:22:00 +0800
> From: Mach Chen <[e-mail]>
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
> To: Greg Mirsky <[e-mail]>om>, Shahram Davari
>         <[e-mail]>
> Cc: Mukund Mani <[e-mail]>om>, [e-mail]
> Message-ID: <3851F6A35FA14D64B6985853F2F12CA5@m55527c>
> Content-Type: text/plain; format=flowed; charset=ISO-8859-1;
>        reply-type=original
>
> Hi Greg and Shahram,
>
> Thanks for your response!
>
> I have a little bit confusion about unidirectional and bidirectional BFD
> session (and I failed to find where have these definitions). Do you mean
> that unidirectional BFD session only has forward path and no return path?
> My
> understanding about a BFD session is that it should have both forward and
> return paths, and if this is true and assume to setup separate BFD session
> for each direction of an associated bidirectional LSP, then the PEs of the
> LSP will failed to demultiplex the BFD sessions.
>
> Best regards,
> Mach
>
> --------------------------------------------------
> From: "Greg Mirsky" <[e-mail]>
> Sent: Saturday, June 12, 2010 3:02 AM
> To: "Shahram Davari" <[e-mail]>
> Cc: "Mach Chen" <[e-mail]>om>; "Mukund Mani" <[e-mail]>om>;
> <[e-mail]>
> 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;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
>