Re: [mpls-tp] Demultiplexing to BFD sessions

Hi Mukund,

I believe we all understand the issues popped up by you and Apratim, and I 
think they need to be discussed further. (Apratim has described them 
clearly in another mail)
I agree with you that CC and CV modes should be merged. As I know it has 
been discussed and still an open issue.
As to treat the using of LSP Ping for bootstrap as a mis-connectivity 
check, I don't think like that. IMO the LSP Ping, as an on-demand OAM 
tool, can't substitute all or part of BFD function which performs quick 
and continuous check of continuity and connectivity.

Best Regards,
Xiao Min

Mukund Mani <mukund.mani@gmail.com> 
2010-06-29 01:39

收件人
Apratim Mukherjee <AMukherjee@ixiacom.com>om>, "xiao.min2@zte.com.cn" 
<xiao.min2@zte.com.cn>
抄送
"mpls-tp-bounces@ietf.org" <mpls-tp-bounces@ietf.org>rg>, "mpls-tp@ietf.org" 
<mpls-tp@ietf.org>
主题
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