Re: [mpls-tp] Demultiplexing to BFD sessions

[Greg Mirsky <[e-mail]>]

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
>
>  ------------------------------
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Tuesday, June 29, 2010 9:27 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 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
>
> 2010/6/29 David Allan I <[e-mail]>
>
>>  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:[e-mail]]
>> *Sent:* Tuesday, June 29, 2010 2:18 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 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 <[e-mail]>
>>
>>>  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:* [e-mail] [mailto:[e-mail]] *On
>>> Behalf Of *Shahram Davari
>>> *Sent:* Tuesday, June 29, 2010 1:31 PM
>>> *To:* Mukund Mani; Apratim Mukherjee; [e-mail]
>>>
>>> *Cc:* [e-mail]; [e-mail]
>>> *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:* [e-mail] [mailto:[e-mail]] *On
>>> Behalf Of *Mukund Mani
>>> *Sent:* Monday, June 28, 2010 10:39 AM
>>> *To:* Apratim Mukherjee; [e-mail]
>>> *Cc:* [e-mail]; [e-mail]
>>> *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 <[e-mail]>
>>>
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> mpls-tp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>
>>>
>>
>