Re: [mpls-tp] Demultiplexing to BFD sessions

Hi Xiao/Apratim

I think discriminators are needed in some of the cases (eg explicit NULL) as
mentioned below. This is what I was trying to state
in my initial mails.
Should it also seen on the lines that LSP Ping itself, if used, for
bootstrap can help in performing a sort of a mis-connectivity check (In CV
mode this is done via the MEP id included in the BFD control packet. In CC
mode the MEP id is not included)
Though I feel that CC and CV mode should be collapsed to one (CV) but thats
another discussion (or probably already discussed)

With Regards
Mukund

2010/6/28 Apratim Mukherjee <AMukherjee@ixiacom.com>

>  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:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On
> Behalf Of *xiao.min2@zte.com.cn
> *Sent:* Monday, June 28, 2010 7:57 AM
> *To:* Mukund Mani
> *Cc:* mpls-tp-bounces@ietf.org; mpls-tp@ietf.org
> *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 <mukund.mani@gmail.com>*
> 发件人:  mpls-tp-bounces@ietf.org
>
> 2010-06-11 14:24
>
> 收件人
>
> mpls-tp@ietf.org
>
> 抄送
>
> 主题
>
> [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
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp
>