Re: [mpls-tp] Demultiplexing to BFD sessions

[Greg Mirsky <[e-mail]>]

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

On Wed, Jun 30, 2010 at 12:30 PM, David Allan I
<[e-mail]> wrote:
>
> 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
> ________________________________
> From: Greg Mirsky [mailto:[e-mail]]
> Sent: Wednesday, June 30, 2010 3:19 PM
> To: David Allan I
> Cc: Shahram Davari; Mukund Mani; Apratim Mukherjee; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>
> 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 <[e-mail]>
>>
>> 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