Re: [mpls-tp] Demultiplexing to BFD sessions

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Lavanya Srivatsa writes:
>  
> 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.

A sure path to failure is to ignore issues of interoperability with a
very large base of deployed hardware even if it is another vendor's
hardware.  That applies to product as well as protocol work.

We should not build OAM mechanisms that can not possibly interoperate
with the existing base of deployed hardware unless we want to
eliminate MPLS-TP applicability to deployed networks (and in doing so
hinder MPLS-TP deployment).

It may be that LM and DM cannot be provided with PHP because it is not
possible to count packets per LSP after the PHP LSR has removed the
top label, but it should still be possible to support CC/CV and most
other OAM functions.

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