Re: [mpls-tp] Demultiplexing to BFD sessions

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]>wrote;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
>> 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 <[e-mail]> wrote:
>>
>>> 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" <[e-mail]>
>>> Sent: Saturday, June 12, 2010 3:02 AM
>>> To: "Shahram Davari" <[e-mail]>
>>> Cc: "Mach Chen" <[e-mail]>om>; "Mukund Mani" <[e-mail]>om>;
>>> <[e-mail]>
>>>
>>> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>>>
>>> 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 <[e-mail]
>>>> >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:[e-mail]]
>>>>> *Sent:* Friday, June 11, 2010 11:18 AM
>>>>> *To:* Shahram Davari
>>>>> *Cc:* Mach Chen; Mukund Mani; [e-mail]
>>>>>
>>>>> *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 <[e-mail]>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Why would one need to run more than one BFD session over an LSP?
>>>>>
>>>>> Thanks,
>>>>> Shahram
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>> Behalf
>>>>> Of Mach Chen
>>>>> Sent: Friday, June 11, 2010 3:05 AM
>>>>> To: Mukund Mani; [e-mail]
>>>>> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>>>>>
>>>>> 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" <[e-mail]>
>>>>> Sent: Friday, June 11, 2010 2:24 PM
>>>>> To: <[e-mail]>
>>>>> Subject: [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
>>>>> > <http://tools.ietf.org/html/draft-ietf-mpls-tp-bfd-cc-cv-00>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> > _______________________________________________
>>>>> > 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mpls-tp mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>