Re: [mpls-tp] Demultiplexing to BFD sessions

[Greg Mirsky <[e-mail]>]

Dear Apratim,
you've said "For Section though the context is gained from the incoming port
id + presence of single GAL Label ..."
I'd note that MPLS-TP section might be not only directly mapped to a
physical port but in essence be server layer LSP (tunnel). Thus, in my view,
in case of MPLS-TP section, as well as in other cases the context deduced
from entire MPLS label stack that precedes the GAL.

Regards,
Greg

On Mon, Jun 28, 2010 at 10:01 AM, Apratim Mukherjee
<[e-mail]>wrote;wrote:

> HI Xiao ,
>
> I do agree with your statement that RFC5885 mechanisms work for PWs as well
> as LSPs and Sections .( For Section though the context is gained from the
> incoming port id + presence of single GAL Label as per
> draft-ietf-mpls-tp-oam-framework-06 Section 3.3 )
>
> My intention was more to point out that some scenarios appear to exist
> where it is not possible for receiving node to find the matching mpls-tp lsp
> for which an OAM packet is received from the label stack .
>
> These scenarios specifically are :
> 1) Implicit NULL / Explicit-NULL assignment by egress
>        Looks to be specifically disallowed due to
>       Section 2.3 of RFC5654
>       “38  A transport path on a link MUST be uniquely identifiable by a
> single label on that link.”
>   This appears to disallow BOTH PHP and Explicit NULL assignment by egress
> in MPLS-TP context so should not be
>   a concern. This in turn allows mpls-bfd for mpls-tp to use label stack as
> demultiplexer instead of
>   discriminator.
>
> 2)  ‘Independent’ BFD sessions ,where two separate BFD sessions perform CC
> check on two directions of a bidirectional lsp/pw in which even if LERs
> assign label >= 16 , the label stack in incoming OAM BFD packet does not
> appear to be enough to locate matching BFD session out of the two BFD
> sessions created for the bi-dir LSP.
>   (  one solution though might be to distinguish between the BFD packets
> for the two sessions based on Min Rx Interval = zero or not zero in the BFD
> PDU. )
>   -- this is just my understanding. Waiting for a reply from the draft
> authors for this issue.
>
> Regards,
> Apratim
>
>
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, June 28, 2010 4:33 PM
> To: Apratim Mukherjee
> Cc: [e-mail]; [e-mail]; Mukund Mani
> Subject: RE: RE: [mpls-tp] Demultiplexing to BFD sessions
>
>
> Hi Apratim,
>
> Acc to RFC5860 section 2.2, "It is RECOMMENDED that any protocol solution,
> meeting one or more functional requirement(s), be the same for PWs, LSPs,
> and Sections." Although this is not a MUST requirement, it's preferred that
> uniform consideration to discriminator in BFD session is applied to PWs,
> LSPs and Sections in the MPLS-TP context.
> So IMO the mechanism defined in RFC5885 also works for MPLS-TP LSP, and
> Implicit NULL or Explicit NULL label should be taken into specific account
> separately.
>
> Best Regards,
> Xiao Min
>
>
> Apratim Mukherjee <[e-mail]>
> 2010-06-28 12:38
> 收件人
> "[e-mail]" <[e-mail]>cn>, Mukund Mani <
> [e-mail]>
> 抄送
> "[e-mail]" <[e-mail]>rg>, "[e-mail]"
> <[e-mail]>
> 主题
> RE: [mpls-tp] Demultiplexing to BFD sessions
>
>
>
>
>
>
>
> Hi Xiao/Mukund ,
>
> I think for normal bi-directional ‘fate-sharing’ BFD bidirectional session
> with no PHP and no explicit NULL assignment at the egress , the bootstrap
> mechanism is not really needed since the Label Stack does provide the
> context at the receiving end for identifying the local BFD session.
> ( same as how IP header gives the context for IPv4 BFD with Your
> Discriminator ‘0’ )
>
> RFC5885 works fine without knowing  peer Discriminator value from before
> since this is a PW connection , which means that egress assigns a label
> which is NOT Implicit NULL or Explicit NULL.
>
> However , this does not appear to work if egress has assigned Implicit NULL
> or Explicit NULL . ( Not clear if both are disallowed , appears to me at
> least first one is not supported in MPLS-TP but nowhere Explicit NULL is
> explicitly ruled out  ) . For MPLS-TP , the mechanisms being designed should
> work for normal LSPs as well ( not only for PWs that is ) .
>
> The other case where above does not appear to work is for ‘independent’ BFD
> sessions . ( I had sent a mail regarding that , but no replies yet ) in
> which two ‘non fate-sharing’ BFD sessions are required to protect each
> direction of a bi-directional connection separately. There also it does not
> look like we can derive local  BFD session correctly from a packet received
> with ‘Your Discriminator’ set to 0 .
>
> Regards,
> Apratim
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of [e-mail]
> Sent: Monday, June 28, 2010 7:57 AM
> To: Mukund Mani
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>
>
> Hi Mukund,
>
> To my understanding, discriminator exchange is applicable in some scenario,
> but not necessary in other scenario, for BFD session bootstrap.
>
> In RFC5884 section 3.2, it's indicated that LSP Ping is used to exchange
> discriminator and bootstrap the BFD session; But in RFC5885 section 3.1,
> it's also indicated that the VCCV control channel provides the context
> required to bootstrap the BFD session and no discriminator exchange needed.
>
> In the MPLS-TP context, IMO it's similar to the scenario in RFC5885 and no
> discriminator exchange is needed to bootstrap BFD session.
>
> Best Regards,
> Xiao Min
> Mukund Mani <[e-mail]>
> 发件人:  [e-mail]
> 2010-06-11 14:24
>
> 收件人
> [e-mail]
> 抄送
>
> 主题
> [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
> _______________________________________________
> 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
>