Re: [mpls-tp] Demultiplexing to BFD sessions

Shahram,

What the Dataplane I-D (http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-data-plane) actually says regarding PHP is the following:

"PHP Penultimate Hop Popping (PHP) MUST be disabled by default."

So, your assertion that that PHP is not allowed in MPLS-TP is incorrect.

This means that we cannot rely on UHP in all situations and that the discriminator is needed.

Thanks,

John

> -----Original Message-----
> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf
> Of David Allan I
> Sent: Tuesday, June 29, 2010 11:04 AM
> To: Shahram Davari; Mukund Mani; Apratim Mukherjee; xiao.min2@zte.com.cn
> Cc: mpls-tp@ietf.org; mpls-tp-bounces@ietf.org
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
> 
> But if the goal is to leverage a common implementation the discriminator
> needs to be present. There should be a further check that the label of
> arrival is correct for a given discriminator.
> 
> Hence one primary state indexing mechanism, and further more authoritative
> tests of correctness chain from that..
> 
> my 2 cents
> D
> 
> ________________________________
> 
> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf
> Of Shahram Davari
> Sent: Tuesday, June 29, 2010 1:31 PM
> To: Mukund Mani; Apratim Mukherjee; xiao.min2@zte.com.cn
> Cc: mpls-tp-bounces@ietf.org; mpls-tp@ietf.org
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
> 
> 
> 
> Hi,
> 
> 
> 
> Discriminator should not be required for MPLS-TP since Explicit Null and
> PHP are not allowed in MPLS-TP.  For MPLS-TP the Label should be enough to
> provide the demultiplexing context.
> 
> 
> 
> Regards,
> 
> Shahram
> 
> 
> 
> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf
> Of Mukund Mani
> Sent: Monday, June 28, 2010 10:39 AM
> To: Apratim Mukherjee; xiao.min2@zte.com.cn
> Cc: mpls-tp@ietf.org; mpls-tp-bounces@ietf.org
> Subject: 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
> 
> 