Re: [mpls-tp] Demultiplexing to BFD sessions

[Apratim Mukherjee <[e-mail]>]

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