Subject: [mpls-tp] Demultiplexing to BFD sessions

From: Mukund Mani <[email-masked]>
Date: Fri, 11 Jun 2010 11:54:11 +0530

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
 <http://tools.ietf.org/html/draft-ietf-mpls-tp-bfd-cc-cv-00>

---

From: Mach Chen <[email-masked]>
Date: Fri, 11 Jun 2010 18:04:49 +0800

Hi Mukund,

I also have the same question about this.

As to the BFD discriminator, IMHO, we should keep using it as it be, because 
it may not be enough to demultiplex the BFD session only based on the label, 
this is especially true when there are more than two BFD sessions over the 
LSP.

BTW, it seems that explicit null label distribution is not excluded (and 
IMHO it should be excluded as PHP) in MPLS-TP (do I miss something?) , and 
it is one of the issues that LSP-Ping for BFD session bootstrap is trying to 
reslove.

Best regards,
Mach

--------------------------------------------------
From: "Mukund Mani" <[email-masked]>
Sent: Friday, June 11, 2010 2:24 PM
To: <[email-masked]>
Subject: [mpls-tp] Demultiplexing to BFD sessions

> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 11 Jun 2010 11:03:10 -0700

Hi,

Why would one need to run more than one BFD session over an LSP?

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Friday, June 11, 2010 3:05 AM
To: Mukund Mani; [email-masked]
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Hi Mukund,

Best regards,
Mach

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 11 Jun 2010 11:18:22 -0700

Dear Shahram,
assume one BFD session is applied to an associated bi-directional LSP. Then
failure in one direction will bring the session in Down state which is not
desired behavior for independent protection mode. Thus, I think, need for
two BFD, in essence unidirectional, sessions.

Regards,
Greg

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 11 Jun 2010 11:54:07 -0700

Hi Greg,

I assume by independent protection mode you mean unidirectional protection. If unidirectional protection is required, then it is simpler to not use  bidirectional BFD session.

Regards,
Shahram

From: Greg Mirsky [mailto:[email-masked]]
Sent: Friday, June 11, 2010 11:18 AM
To: Shahram Davari
Cc: Mach Chen; Mukund Mani; [email-masked]
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Dear Shahram,
assume one BFD session is applied to an associated bi-directional LSP. Then failure in one direction will bring the session in Down state which is not desired behavior for independent protection mode. Thus, I think, need for two BFD, in essence unidirectional, sessions.

Regards,
Greg
On Fri, Jun 11, 2010 at 11:03 AM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks,
Shahram

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mach Chen
Sent: Friday, June 11, 2010 3:05 AM
To: Mukund Mani; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Hi Mukund,

Best regards,
Mach

--------------------------------------------------
From: "Mukund Mani" <[email-masked]<mailto:[email-masked]>>
Sent: Friday, June 11, 2010 2:24 PM
To: <[email-masked]<mailto:[email-masked]>>
Subject: [mpls-tp] Demultiplexing to BFD sessions

> [email-masked]<mailto:[email-masked]>
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 11 Jun 2010 12:02:43 -0700

Hi Shahram,
yes, we need to settle on terminology related to protection.
It was discussed and presented at the last IETF meeting how bi-directional
BFD session easily can operate in, effectively, unidirectional mode. I think
that operating BFD session in this mode is applicable to unidirectional and
associated bi-directional p2p LSPs.

Regards,
Greg

On Fri, Jun 11, 2010 at 11:54 AM, Shahram Davari <[email-masked]>wrote:

>  Hi Greg,
>
>
>
> I assume by independent protection mode you mean unidirectional protection.
> If unidirectional protection is required, then it is simpler to not use
>  bidirectional BFD session.
>
>
>
> Regards,
>
> Shahram
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Friday, June 11, 2010 11:18 AM
> *To:* Shahram Davari
> *Cc:* Mach Chen; Mukund Mani; [email-masked]
>
> *Subject:* Re: [mpls-tp] Demultiplexing to BFD sessions
>
>
>
> Dear Shahram,

---

From: Mach Chen <[email-masked]>
Date: Sat, 12 Jun 2010 09:51:12 +0800

Hi Loa,

Actually I do not intent to exclude the ATM based LSRs in MPLS-TP networks, 
I am just wondering that if the Egress LSR allocates explicit null labels to 
its upstream neighbours, then how to determine to which LSP the received 
MPLS-TP OAM message LSP belongs only based on the explicit null label?  It 
seems that it has the same issue as PHP. Is my understanding correct?

Best regards,
Mach

--------------------------------------------------
From: "Loa Andersson" <[email-masked]>
Sent: Friday, June 11, 2010 6:20 PM
To: "Mach Chen" <[email-masked]>; "Mukund Mani" <[email-masked]>; 
<[email-masked]>
Subject: RE: [mpls-tp] Demultiplexing to BFD sessions

> Mike,
>
> looking at the not very likely cases. It is possible to
> run LSPs or mpls controlled ATM switches, we need the explicit
> null labels to do this, would we like to build anything into
> the standards that exclude ATM based LSRs from mpls-tp networks?
>
> /Loa
>
>> Sent: den 11 juni 2010 12:05
>> > But *draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 *specifies that
>> LSP
>> > Ping
>> > Also as a part of MPLS-TP OAM could somebody explain why such a
>> deviation
>> > is

---

From: Mach Chen <[email-masked]>
Date: Sat, 12 Jun 2010 10:22:00 +0800

Hi Greg and Shahram,

Thanks for your response!

I have a little bit confusion about unidirectional and bidirectional BFD 
session (and I failed to find where have these definitions). Do you mean 
that unidirectional BFD session only has forward path and no return path? My 
understanding about a BFD session is that it should have both forward and 
return paths, and if this is true and assume to setup separate BFD session 
for each direction of an associated bidirectional LSP, then the PEs of the 
LSP will failed to demultiplex the BFD sessions.

Best regards,
Mach

--------------------------------------------------
From: "Greg Mirsky" <[email-masked]>
Sent: Saturday, June 12, 2010 3:02 AM
To: "Shahram Davari" <[email-masked]>
Cc: "Mach Chen" <[email-masked]>; "Mukund Mani" <[email-masked]>; 
<[email-masked]>
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf
>> Of Mach Chen

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 12 Jun 2010 08:31:37 +0100

Greg'n'Shahram,

Please do check the terminology with the Survivability Framework.
It is (just) not too late to tweak if we have got something wrong or left 
something out.

cheers,
Adrian
----- Original Message ----- 
From: "Greg Mirsky" <[email-masked]>
To: "Shahram Davari" <[email-masked]>
Cc: "Mukund Mani" <[email-masked]>; <[email-masked]>
Sent: Friday, June 11, 2010 8:02 PM
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

>> it is one of the issues that LSP-Ping for BFD session bootstrap is trying

--------------------------------------------------------------------------------

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 13 Jun 2010 18:24:03 -0700

Dear Mach,
you'll recall that the first versions of MPLS-TP Proactive CC/CV were based
on work of BFD WG for multipoint network. If my understanding of it correct
BFD session is unidirectional and that required change to BFD Base in regard
to session de-multiplexing. At the last IETF we had discussion and
presentation on how  BFD base can be ran as unidirectional - by source
setting its Required Min RX Interval to zero. As result, the remote node
must not send any periodic BFD control packet. That is what I've referred in
my earlier comment. And if we take in consideration that MPLS-TP OAM must be
able to be instantiated, function without Control Plane, then this mode must
be configurable by NMS, perhaps even without assistance of LSP Ping
bootstrapping BFD session over LSP. But that, I think, is outside of this
discussion.

Regards,
Greg

On Fri, Jun 11, 2010 at 7:22 PM, Mach Chen <[email-masked]> wrote:

>> On Fri, Jun 11, 2010 at 11:54 AM, Shahram Davari <[email-masked]
>> >wrote:
>>
>>   Hi Greg,
>>>
>>>
>>>
>>> > Also as a part of MPLS-TP OAM could somebody explain why such a >
>>> deviation
>>> > is

---

From: Mukund Mani <[email-masked]>
Date: Mon, 14 Jun 2010 20:35:34 +0530

Hi Greg

Still on this regard, for the BFD session on the source, to come to the UP
state, it would be done based on the remote peer's BFD state for that
session. Or do I understand that the BFD session on the source would be only
administratively driven?

With Regards
Mukund

On Mon, Jun 14, 2010 at 6:54 AM, Greg Mirsky <[email-masked]> wrote:

>>>> it is one of the issues that LSP-Ping for BFD session bootstrap is
>>>> trying
>>>> to
>>>> reslove.
>>>>
>>>> Best regards,
>>>> Mach
>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 14 Jun 2010 10:25:34 -0700

Dear Mukund,
on another discussion thread John have mentioned upcoming updates to the
cc-cv-rdi document. It might be that these updates will address your
question as well. Personally, I'd consider removing handshake between
end-points of BFD session. The state machine then is like one described in
BFD for Multipoint Networks.

Regards,
Greg

On Mon, Jun 14, 2010 at 8:05 AM, Mukund Mani <[email-masked]> wrote:

> On Mon, Jun 14, 2010 at 6:54 AM, Greg Mirsky <[email-masked]>wrote:
>
>> Dear Mach,
>> you'll recall that the first versions of MPLS-TP Proactive CC/CV were
>> based on work of BFD WG for multipoint network. If my understanding of it
>> correct BFD session is unidirectional and that required change to BFD Base
>> in regard to session de-multiplexing. At the last IETF we had discussion and
>>>>> > "MPLS labels at peer MEPs are used to provide context for the
>>>>> received
>>>>> BFD
>>>>> > packets."
>>>>> >
>>>>> > values are not required for demultiplexing to the BFD session
>>>>> anymore, > we

---

From: [email-masked]
Date: Mon, 28 Jun 2010 10:26:44 +0800

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 <[email-masked]> 
发件人:  [email-masked]
2010-06-11 14:24

收件人
[email-masked]
抄送

主题
[mpls-tp] Demultiplexing to BFD sessions

Hi TP-Group
 
draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 states in Section 3

draft-ietf-mpls-tp-bfd-cc-cv-00 states in Section 3.5.6 

 
But draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 specifies that LSP Ping 
can also be used to signal BFD discriminator.

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.... 

With Regards
Mukund

---

From: Apratim Mukherjee <[email-masked]>
Date: Sun, 27 Jun 2010 21:38:15 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 28, 2010 7:57 AM
To: Mukund Mani
Cc: [email-masked]; [email-masked]
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

2010-06-11 14:24

收件人

[email-masked]

抄送

主题

Hi TP-Group

"When using BFD over MPLS-TP LSPs, the BFD discriminator MUST either be signaled via LSP-Ping or be statically configured."

"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.

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....

With Regards
Mukund

---

From: [email-masked]
Date: Mon, 28 Jun 2010 19:02:52 +0800

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 <[email-masked]> 
2010-06-28 12:38

收件人
"[email-masked]" <[email-masked]>, Mukund Mani 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
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: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Monday, June 28, 2010 7:57 AM
To: Mukund Mani
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Hi Mukund, 

Best Regards, 
Xiao Min 

收件人
[email-masked] 
抄送

主题

Hi TP-Group 

  

  

  

With Regards 
Mukund

---

From: Apratim Mukherjee <[email-masked]>
Date: Mon, 28 Jun 2010 07:01:27 -0700

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: [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 28, 2010 4:33 PM
To: Apratim Mukherjee
Cc: [email-masked]; [email-masked]; 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 <[email-masked]> 
2010-06-28 12:38 
收件人
"[email-masked]" <[email-masked]>, Mukund Mani <[email-masked]> 
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
主题
RE: [mpls-tp] Demultiplexing to BFD sessions

Hi Xiao/Mukund , 

  

Regards, 
Apratim 

Hi Mukund, 

Best Regards, 
Xiao Min 

收件人
[email-masked] 
抄送

主题

Hi TP-Group 

 

 

 

With Regards 
Mukund

---

From: Mukund Mani <[email-masked]>
Date: Mon, 28 Jun 2010 23:09:04 +0530

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 <[email-masked]>

>  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.
>
> 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:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of [email-masked]
> *Sent:* Monday, June 28, 2010 7:57 AM
> *To:* Mukund Mani
> *Cc:* [email-masked]; [email-masked]
> To my understanding, discriminator exchange is applicable in some scenario,
> but not necessary in other scenario, for BFD session bootstrap.
>
> required to bootstrap the BFD session and no discriminator exchange needed.
>
>   *Mukund Mani <[email-masked]>*
> But *draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 *specifies that LSP
> Ping can also be used to signal BFD discriminator.
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Jun 2010 14:50:11 -0400

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
<[email-masked]>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 .
>
> 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. )
> 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.

---

From: [email-masked]
Date: Tue, 29 Jun 2010 10:21:13 +0800

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

2010-06-29 01:39

收件人
Apratim Mukherjee <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
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

 

 
Regards,
Apratim

Hi Mukund, 

Best Regards, 
Xiao Min 

收件人
[email-masked] 
抄送

主题

Hi TP-Group 

  

 

 

With Regards 
Mukund

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 29 Jun 2010 10:31:04 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Mukund Mani
Sent: Monday, June 28, 2010 10:39 AM
To: Apratim Mukherjee; [email-masked]
Cc: [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>>
Hi Xiao/Mukund ,

Regards,
Apratim
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, June 28, 2010 7:57 AM
To: Mukund Mani
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Hi Mukund,

Best Regards,
Xiao Min

Mukund Mani <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2010-06-11 14:24

收件人

抄送

主题

Hi TP-Group

With Regards
Mukund

---

From: David Allan I <[email-masked]>
Date: Tue, 29 Jun 2010 14:03:41 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, June 29, 2010 1:31 PM
To: Mukund Mani; Apratim Mukherjee; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Hi,

Regards,
Shahram

Hi Xiao/Apratim

With Regards
Mukund

Regards,
Apratim

Hi Mukund,

Best Regards,
Xiao Min

2010-06-11 14:24

收件人

抄送

主题

Hi TP-Group

With Regards
Mukund

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 29 Jun 2010 11:18:13 -0700

Dear David,
I tend to agree with Shahram that for MPLS-TP discriminator check even for
bi-directional p2p path is optional. And for uni-directional, recalling BFD
for multi-point network, demultiplexing mechanism was modified when compared
with BFD base. Said that I realize that to be interoperable an
implementation will have to support the discriminator check perhaps as
default behavior. Well, unless we agree that the discriminator has no role
in demultiplexing OAM/BFD sessions between same pair of nodes at all. Which
will make discriminator field unnecessary as well as mechanisms of
exchanging them (LSP Ping bootstrap of BFD session). That will, in my view,
simplify the OAM solution based on BFD.

another .02 in the bank

Regards,
Greg

2010/6/29 David Allan I <[email-masked]>

>  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.
>
>  ------------------------------
> Behalf Of *Shahram Davari
> *Sent:* Tuesday, June 29, 2010 1:31 PM
> *To:* Mukund Mani; Apratim Mukherjee; [email-masked]
>
> 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
>
>
>
> Behalf Of *Mukund Mani
> *Sent:* Monday, June 28, 2010 10:39 AM
> *To:* Apratim Mukherjee; [email-masked]
> *Cc:* [email-masked]; [email-masked]
> 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

---

From: David Allan I <[email-masked]>
Date: Tue, 29 Jun 2010 14:36:02 -0400

My understanding (and the text in 6.3 of RFC 5880 agrees with me) that the discriminator value is per platform unique, and not necessarily confined to a having uniqueness to a particular node pair.

So local state can be indexed directly via the discriminator for any BFD packet received by a node.

cheers
D

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Tuesday, June 29, 2010 2:18 PM
To: David Allan I
Cc: Shahram Davari; Mukund Mani; Apratim Mukherjee; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Dear David,
I tend to agree with Shahram that for MPLS-TP discriminator check even for bi-directional p2p path is optional. And for uni-directional, recalling BFD for multi-point network, demultiplexing mechanism was modified when compared with BFD base. Said that I realize that to be interoperable an implementation will have to support the discriminator check perhaps as default behavior. Well, unless we agree that the discriminator has no role in demultiplexing OAM/BFD sessions between same pair of nodes at all. Which will make discriminator field unnecessary as well as mechanisms of exchanging them (LSP Ping bootstrap of BFD session). That will, in my view, simplify the OAM solution based on BFD.

another .02 in the bank

Regards,
Greg

2010/6/29 David Allan I <[email-masked]<mailto:[email-masked]>>
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.

my 2 cents
D

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Shahram Davari
Sent: Tuesday, June 29, 2010 1:31 PM
To: Mukund Mani; Apratim Mukherjee; [email-masked]<mailto:[email-masked]>

Hi,

Regards,
Shahram

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mukund Mani
Sent: Monday, June 28, 2010 10:39 AM
To: Apratim Mukherjee; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Hi Xiao/Apratim

With Regards
Mukund

Regards,
Apratim

Hi Mukund,

Best Regards,
Xiao Min

2010-06-11 14:24

收件人

抄送

主题

Hi TP-Group

With Regards
Mukund

---

From: John E Drake <[email-masked]>
Date: Tue, 29 Jun 2010 11:59:20 -0700

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

> Of David Allan I
> Sent: Tuesday, June 29, 2010 11:04 AM
> To: Shahram Davari; Mukund Mani; Apratim Mukherjee; [email-masked]
> Of Shahram Davari
> Of Mukund Mani
> 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: Greg Mirsky <[email-masked]>
Date: Tue, 29 Jun 2010 18:27:06 -0700

Dear David,
received in Your Discriminator value is unique for the receiver and not
necessarily for the sender of the BFD control packet. Transmitting in every
CV/CC/RDI packet discriminator along with Unique MEP ID, in my view, is
redundant.

Regards,
Greg

>  My understanding (and the text in 6.3 of RFC 5880 agrees with me) that
> the discriminator value is per platform unique, and not necessarily confined
> to a having uniqueness to a particular node pair.
>
> *Sent:* Tuesday, June 29, 2010 2:18 PM
> *To:* David Allan I
> *Cc:* Shahram Davari; Mukund Mani; Apratim Mukherjee; [email-masked];
> [email-masked]; [email-masked]
>
>> bootstrap mechanism is not really needed since the Label Stack does provide
>> the context at the receiving end for identifying the local BFD session.
>>
>> at least first one is not supported in MPLS-TP but nowhere Explicit NULL is

---

From: Apratim Mukherjee <[email-masked]>
Date: Tue, 29 Jun 2010 21:20:23 -0700

Hi

Leaving aside PHP , Implicit NULL and Explicit NULL which as per   Section 2.3 of RFC5654  Requirements of an MPLS Transport Profile
“38  A transport path on a link MUST be uniquely identifiable by a single label on that link.”  appears to disallow BOTH PHP and Explicit NULL assignment by egress in MPLS-TP context . Hope this understanding is correct.  
Probably , the reference by John in his mail  from (http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-data-plane) "PHP Penultimate Hop Popping (PHP) MUST be disabled by default." is misleading sinceit does not talk about Explicit NULL issue and does not seem to be aligned with the Requirements RFC which should take precedence. Maybe needs to be updated ? 

However , below arguments that always we can derive BFD session from label stack does not appear correct in one particular case (ruling out Explicit NULL and Implicit NULL assignment by egress for MPLS-TP)  :

draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD: ( This is from a previous mail to which I did not get any replies ) 
Situation : BFD is providing independent service over the Tx and Rx links of an active bidirectional MPLS-TP LSP  (say because this lsp is part of a 1+1 protection group supporting uni-directional protection switching )
               Node A                       Node B 
               OutLabel = L11                 InLabel  = L11
               InLabel  = L12                 OutLabel = L12
This bidirectional LSP is configured to run two *independent* BFD sessions , one BFD session helping Node B to detect that its Rx connection via InLabel L11 is good , and the other helping Node A to detect that its Rx connection via InLabel L12 is good.
Node A receives two sets of BFD control packets : 
1) For the session in which it is 'active' ( rarely, during state changes only),i.e. these packets have MinRxInterval set to 0
2) The BFD packets Node A receives for the session in which it is 'passive', every 3.33/10ms will be identical if BFD packet for both sessions contain 0 in 'Your Discriminator' field .

Hence , if the two sessions were to be independent , the Discriminators need to be present and right from the first packet (i.e. cannot be 0 in initial packet ) . Or separate mechanism must be identified. Deriving the BFD session from the label stack alone appears to be not possible in this case.  It is from same source to same destination using same label stack.

Possible solutions if above problem is real and the analysis is correct :
1) Mandatory use of pre-exchange of Discriminators via LSP Ping or manual configuration before running BFD in ‘independent mode’.i.e no BFD packet contains 0 Your Discriminator when running in ‘independent mode’ ( Discriminator becomes must) 
OR
2) If ‘Your Discriminator’ is 0 , use Label Stack + Min Rx Interval ( 0 / non-zero ) to derive packet is for which session.-> does not look good at all  but does completely remove Discriminator from being part of session demultiplexer .
3) Implement ‘independent’ BFD sessions in  some other manner.

Please share your comments.

Regards,
Apratim

=============================================================================================================
From: Greg Mirsky [mailto:[email-masked]] 
Sent: Wednesday, June 30, 2010 6:57 AM
To: David Allan I
Cc: Shahram Davari; Mukund Mani; Apratim Mukherjee; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Dear David,
received in Your Discriminator value is unique for the receiver and not necessarily for the sender of the BFD control packet. Transmitting in every CV/CC/RDI packet discriminator along with Unique MEP ID, in my view, is redundant.

Regards,
Greg

cheers
D

________________________________________
From: Greg Mirsky [mailto:[email-masked]] 
Sent: Tuesday, June 29, 2010 2:18 PM
To: David Allan I
Cc: Shahram Davari; Mukund Mani; Apratim Mukherjee; [email-masked]; [email-masked]; [email-masked]

Dear David,

another .02 in the bank

Regards,
Greg

my 2 cents
D

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, June 29, 2010 1:31 PM
To: Mukund Mani; Apratim Mukherjee; [email-masked] 

Hi,

Regards,
Shahram

Hi Xiao/Apratim

With Regards
Mukund

 

Regards,
Apratim

Hi Mukund, 

Best Regards, 
Xiao Min 

主题

Hi TP-Group 

  

  

  

With Regards 
Mukund

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 29 Jun 2010 21:50:59 -0700

Dear Apratim,
please note that even if Your Discriminator == 0 the CC/CV/RDI OAM packet
carries Unique MEP ID. Personally, I don't see benefit of using
discriminator when there's Unique MEP ID. We can make check of Your
Discriminator optional and not affecting state of OAM/BFD session.

Regards,
Greg

On Tue, Jun 29, 2010 at 9:20 PM, Apratim Mukherjee
<[email-masked]>wrote:

> Hi
>
> Leaving aside PHP , Implicit NULL and Explicit NULL which as per   Section
> 2.3 of RFC5654  Requirements of an MPLS Transport Profile
> “38  A transport path on a link MUST be uniquely identifiable by a single
> label on that link.”  appears to disallow BOTH PHP and Explicit NULL
> assignment by egress in MPLS-TP context . Hope this understanding is
> correct.
> Probably , the reference by John in his mail  from (
> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-data-plane) "PHP
> Penultimate Hop Popping (PHP) MUST be disabled by default." is misleading
> sinceit does not talk about Explicit NULL issue and does not seem to be
> aligned with the Requirements RFC which should take precedence. Maybe needs
> to be updated ?
>
> However , below arguments that always we can derive BFD session from label
> stack does not appear correct in one particular case (ruling out Explicit
> NULL and Implicit NULL assignment by egress for MPLS-TP)  :
>
> draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD: ( This is from a
> previous mail to which I did not get any replies )
> Situation : BFD is providing independent service over the Tx and Rx links
> of an active bidirectional MPLS-TP LSP  (say because this lsp is part of a
> 1+1 protection group supporting uni-directional protection switching )
>                Node A                       Node B
> This bidirectional LSP is configured to run two *independent* BFD sessions
> , one BFD session helping Node B to detect that its Rx connection via
> InLabel L11 is good , and the other helping Node A to detect that its Rx
> connection via InLabel L12 is good.
> 1) For the session in which it is 'active' ( rarely, during state changes
> only),i.e. these packets have MinRxInterval set to 0
> 2) The BFD packets Node A receives for the session in which it is
> 'passive', every 3.33/10ms will be identical if BFD packet for both sessions
> contain 0 in 'Your Discriminator' field .
>
> Hence , if the two sessions were to be independent , the Discriminators
> need to be present and right from the first packet (i.e. cannot be 0 in
> initial packet ) . Or separate mechanism must be identified. Deriving the
> BFD session from the label stack alone appears to be not possible in this
> case.  It is from same source to same destination using same label stack.
>
> 1) Mandatory use of pre-exchange of Discriminators via LSP Ping or manual
> configuration before running BFD in ‘independent mode’.i.e no BFD packet
> contains 0 Your Discriminator when running in ‘independent mode’ (
> Discriminator becomes must)
> OR
> 2) If ‘Your Discriminator’ is 0 , use Label Stack + Min Rx Interval ( 0 /
> non-zero ) to derive packet is for which session.-> does not look good at
> all  but does completely remove Discriminator from being part of session
> demultiplexer .
> Cc: Shahram Davari; Mukund Mani; Apratim Mukherjee; [email-masked];
> My understanding (and the text in 6.3 of RFC 5880 agrees with me) that the
> discriminator value is per platform unique, and not necessarily confined to
> a having uniqueness to a particular node pair.
>
> Cc: Shahram Davari; Mukund Mani; Apratim Mukherjee; [email-masked];

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 29 Jun 2010 22:20:34 -0700

Dear Apratim,
I think "independent" OAM uni-directional OAM session requires separate MEG
and, consequently, MEP ID will be unique for each session, direction of the
bi-directional LSP in your scenario. That is why I think that MEP ID TLV
would not be the same as you've suggested.
Your point that MEP ID is not required in CC OAM is absolutely correct. I
think that another reason not to have CC but only CV/RDI.

Regards,
Greg

2010/6/29 Apratim Mukherjee <[email-masked]>

>  Hi Greg
>
>
>
> But in the particular case I am trying to point out, the MEP ID would also
> appear to be same for ‘independent’ BFD sessions. In which case we are back
> to square one. Unless my understanding of ‘independent’ BFD sessions is
> incorrect somewhere which is also possible. (Also note that as current draft
> stands, MEP ID would be there only for CC-CV type , not for CC type of BFD
> OAM packets.)
>
>
>
> In all other cases I do agree that either MEP ID ( globally unique so looks
> safer ) or label stack ( packets could leak to incorrect MEP though in this
> case ) can be used to determine the LSP for which the BFD OAM packet has
> been received.
>
>
>
> Regards,
>
> Apratim
>
> *Sent:* Wednesday, June 30, 2010 10:21 AM
> *To:* Apratim Mukherjee
> *Cc:* David Allan I; Shahram Davari; Mukund Mani; [email-masked];
> On Tue, Jun 29, 2010 at 9:20 PM, Apratim Mukherjee <[email-masked]>
> wrote:
>
> Hi
>
> explicitly ruled out  ) . For MPLS-TP , the mechanisms being designed
> look like we can derive local  BFD session correctly from a packet

---

From: Apratim Mukherjee <[email-masked]>
Date: Tue, 29 Jun 2010 23:37:18 -0700

Hi Greg 

That makes sense and is a good solution. 
However , probably MEP Id currently consists of global id + node id + src tunnel id + dest tunnel id + lsp id ..We will need to either make lspid different for Tx and Rx side ( does not seem to be the case as defined today ) or add + tx/rx identifier to the MEP Id to make it unique. And add requirement that for independent mode at least , BFD should work in CC-CV mode only.

Regards,
Apratim
P.S. Changed back to plain text to meet mail size limit.

==========================================================================================================
From: Greg Mirsky [mailto:[email-masked]] 
Sent: Wednesday, June 30, 2010 10:51 AM
To: Apratim Mukherjee
Cc: David Allan I; Shahram Davari; Mukund Mani; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Dear Apratim,
I think "independent" OAM uni-directional OAM session requires separate MEG and, consequently, MEP ID will be unique for each session, direction of the bi-directional LSP in your scenario. That is why I think that MEP ID TLV would not be the same as you've suggested.
Your point that MEP ID is not required in CC OAM is absolutely correct. I think that another reason not to have CC but only CV/RDI.

Regards,
Greg
==========================================================================================================
2010/6/29 Apratim Mukherjee <[email-masked]>
Hi Greg 
 
But in the particular case I am trying to point out, the MEP ID would also appear to be same for ‘independent’ BFD sessions. In which case we are back to square one. Unless my understanding of ‘independent’ BFD sessions is incorrect somewhere which is also possible. (Also note that as current draft stands, MEP ID would be there only for CC-CV type , not for CC type of BFD OAM packets.)
 
In all other cases I do agree that either MEP ID ( globally unique so looks safer ) or label stack ( packets could leak to incorrect MEP though in this case ) can be used to determine the LSP for which the BFD OAM packet has been received.
 
Regards,
Apratim
===================================================================================================
From: Greg Mirsky [mailto:[email-masked]] 
Sent: Wednesday, June 30, 2010 10:21 AM
To: Apratim Mukherjee
Cc: David Allan I; Shahram Davari; Mukund Mani; [email-masked]; [email-masked]; [email-masked]

Dear Apratim,
please note that even if Your Discriminator == 0 the CC/CV/RDI OAM packet carries Unique MEP ID. Personally, I don't see benefit of using discriminator when there's Unique MEP ID. We can make check of Your Discriminator optional and not affecting state of OAM/BFD session.

Regards,
Greg
On Tue, Jun 29, 2010 at 9:20 PM, Apratim Mukherjee <[email-masked]> wrote:
Hi

Regards,
Apratim

Dear David,

Regards,
Greg

cheers
D

Dear David,

another .02 in the bank

Regards,
Greg

my 2 cents
D

Hi,

Regards,
Shahram

Hi Xiao/Apratim

With Regards
Mukund

 

Regards,
Apratim

Hi Mukund,

Best Regards,
Xiao Min

主题

Hi TP-Group

 

 

 

With Regards
Mukund

---

From: David Allan I <[email-masked]>
Date: Wed, 30 Jun 2010 08:44:22 -0400

Hi Greg:

I've made this point before, the discriminator is simply a receiver administered "helper" for indexing state.

Compare the two simplistic pseudo code examples below...how a recevier checks for a valid MEP ID and received label....

if (bfd_message.mep_ID != recevier_bfd_state[bfd_message.your disciminator].expected_mep_ID]) error...
if (received_label != recevier_bfd_state[bfd_message.your discriminator].expected_label) error...

vs.

for (i=0;i<max_discriminators;i++) {
    if (bfd_message.mep_ID == recevier_bfd_state[i].expected_mep_ID) break;
}
If (i== max_discriminators) error....
if (received_label != receiver_bfd_state[i].expected_label) error...

The these examples are the general case solution that works for all modes of operation of MPLS (including PHP). We can redesign it to index state based on received label but why have two distinct implementations? I thought the goal here was re-use where possible...

I hope this makes it clear...

D

Sent: Tuesday, June 29, 2010 9:27 PM

Dear David,

Regards,
Greg

cheers
D

________________________________
From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, June 29, 2010 2:18 PM
To: David Allan I
Cc: Shahram Davari; Mukund Mani; Apratim Mukherjee; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear David,

another .02 in the bank

Regards,
Greg

my 2 cents
D

Hi,

Regards,
Shahram

Hi Xiao/Apratim

With Regards
Mukund

Regards,
Apratim

Hi Mukund,

Best Regards,
Xiao Min

2010-06-11 14:24

收件人

抄送

主题

Hi TP-Group

With Regards
Mukund

---

From: Mukund Mani <[email-masked]>
Date: Wed, 30 Jun 2010 19:15:59 +0530

Hi Apratim/Greg

IMHO the MEP id will be different.  Eg as far as the identification goes say
the forward direction is from node A to node B, MEP for the forward path can
be identified as A::Tnl X::LSP1 and the reverse path MEP can be identified
as B::Tnl Y::LSP2.

With Regards
Mukund

On Wed, Jun 30, 2010 at 12:07 PM, Apratim Mukherjee
<[email-masked]>wrote:

> However , probably MEP Id currently consists of global id + node id + src
> tunnel id + dest tunnel id + lsp id ..We will need to either make lspid
> different for Tx and Rx side ( does not seem to be the case as defined today
> ) or add + tx/rx identifier to the MEP Id to make it unique. And add
> requirement that for independent mode at least , BFD should work in CC-CV
> mode only.
>
> Regards,
> Apratim
> Cc: David Allan I; Shahram Davari; Mukund Mani; [email-masked];
> Cc: David Allan I; Shahram Davari; Mukund Mani; [email-masked];

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 30 Jun 2010 09:55:35 -0700

Hi,

Also note that Demultiplexing based on your Discriminator is not very practical for BFD CV, since it includes a MEP ID TLV and having TLV makes it very difficult to parse to “your Discriminator field” in HW. Note that TLVs are SW friendly.

In my view you should be able to demultiplex based on Label only and then for further verification optionally check “your discriminator”.

Thx.
Shahram

From: Greg Mirsky [mailto:[email-masked]]
Sent: Tuesday, June 29, 2010 9:51 PM
To: Apratim Mukherjee
Cc: David Allan I; Shahram Davari; Mukund Mani; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Dear Apratim,

Regards,
Greg
On Tue, Jun 29, 2010 at 9:20 PM, Apratim Mukherjee <[email-masked]<mailto:[email-masked]>> wrote:
Hi

Regards,
Apratim

Dear David,

Regards,
Greg

cheers
D

Dear David,

another .02 in the bank

Regards,
Greg

my 2 cents
D

Hi,

Regards,
Shahram

Hi Xiao/Apratim

With Regards
Mukund

Regards,
Apratim

Hi Mukund,

Best Regards,
Xiao Min

主题

Hi TP-Group

With Regards
Mukund

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 30 Jun 2010 12:19:16 -0700

Dear Dave,
thank you for the insight. Though I was under impression we're not talking
about implementations here ;)

In my view, the check whether MEP ID matches your Discriminator is redundant
(well, the implementation has a bug otherwise). The real continuity check is
whether context of a transport channel (label stack) and demultiplexor (MEP
ID or Your Discriminator) match. Since the Unique MEP ID is required, the
discriminator, or at least its role in CV can be optional.

Regards,
Greg

2010/6/30 David Allan I <[email-masked]>

>  Hi Greg:
>
> I've made this point before, the discriminator is simply a receiver
> administered "helper" for indexing state.
>
> Compare the two simplistic pseudo code examples below...how a recevier
> checks for a valid MEP ID and received label....
>
> *if (bfd_message.mep_ID != recevier_bfd_state[bfd_message.your
> disciminator].expected_mep_ID]) error...*
> *if (received_label != recevier_bfd_state[bfd_message.your
> discriminator].expected_label) error...*
>
> vs.
>
> *for (i=0;i<max_discriminators;i++) {*
> *    if (bfd_message.mep_ID == recevier_bfd_state[i].expected_mep_ID)
> break;*
> *}*
> *If (i== max_discriminators) error....*
> *if (received_label != receiver_bfd_state[i].expected_label) error...*
>
> The these examples are the general case solution that works for all modes
> of operation of MPLS (including PHP). We can redesign it to index state
> based on received label but why have two distinct implementations? I thought
> the goal here was re-use where possible...
> **
> *Sent:* Tuesday, June 29, 2010 9:27 PM
>
> *To:* David Allan I
>> *Cc:* Shahram Davari; Mukund Mani; Apratim Mukherjee;
>> [email-masked]; [email-masked]; [email-masked]
>>
>>>  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
>>>
>>> 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
>>>
>>> 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.
>>>

---

From: David Allan I <[email-masked]>
Date: Wed, 30 Jun 2010 15:30:55 -0400

Resend after snipping, the thread has gotten too long...
Hi Greg:

IMO implementation does matter. Why would I postulate a standard that required me to do the same basic function two ways...?

A piece of general purpose MPLS silicon would then need to do both, state indexing by discriminator, and state indexing from the ILM. Which IMO is more gates, more heat, more to go wrong, longer verification cycle. yadda yadda yadda....

cheers
D

Sent: Wednesday, June 30, 2010 3:19 PM

Dear Dave,
thank you for the insight. Though I was under impression we're not talking about implementations here ;)

In my view, the check whether MEP ID matches your Discriminator is redundant (well, the implementation has a bug otherwise). The real continuity check is whether context of a transport channel (label stack) and demultiplexor (MEP ID or Your Discriminator) match. Since the Unique MEP ID is required, the discriminator, or at least its role in CV can be optional.

Regards,
Greg

2010/6/30 David Allan I <[email-masked]<mailto:[email-masked]>>
Hi Greg:

vs.

D

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 30 Jun 2010 22:19:17 -0700

Dear David,
I wouldn't argue with your point - it's practical and reasonable. But
I have noticed that MPLS-TP  Loss and Delay Measurement document
doesn't have discriminator in its control packets. Would LM/DM
sessions require demultiplexing? I think so. Then it'd be beneficial
to have consistency across all MPLS-TP OAM mechanism for the same
functionality. But on the other hand, Unique MEP ID might find its way
into LM/DM packet. Would we have duplication of functionality for
reasons of ease of implementation?

Regards,
Greg