Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Greg,

the update could be in addition of either broadcast or link local multicast
> or both with appropriate normative language. But I would not agree that
> these wouldn't work.
>

Double negatives make it very hard to parse a sentence.

Anyway, why would you NOT agree that this WOULDNT work?

I am telling you that link local multicasts and unicasts are dealt with
differently in the data plane, so the data path being up for the former may
not necessarily mean that its up for the latter as well. So tell me WHY you
think this argument isnt valid? I was the L3 data plane architect in my
former company for one of the product lines and i am telling you that in my
box, which is very very widely deployed, your scheme will NOT work since i
punt all link local packets to the CPU differently. In fact, in some cases
even the TX path is different. So sure, u-BFD may very well claim that the
link is up, but its possible that there may be no IP connectivity.

Cheers, Manav

Regards, Greg
> On Apr 8, 2016 12:34 PM, "Manav Bhatia" <manavbhatia@gmail.com> wrote:
>
>> Hi Greg,
>>
>> Not sure i understand how it can "update RFC 7130". Is that by using a
>> link local mcast IP instead of a Unicast IP?
>>
>> We know that, that wouldnt work.
>>
>> Cheers, Manav
>>
>> On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky <
>> gregory.mirsky@ericsson.com> wrote:
>>
>>> Hi Reshad,
>>>
>>> thank you for your comments. Indeed, RFC 7130 is restricted and thus
>>> hardly applicable to MC-LAG case. We realize that if this proposal is
>>> adopted it not only enhance applicability on u-BFD but will update RFC 7130.
>>>
>>>
>>>
>>> Regards,
>>>
>>>                                 Greg
>>>
>>>
>>>
>>> *From:* Reshad Rahman (rrahman) [mailto:rrahman@cisco.com]
>>> *Sent:* Friday, April 08, 2016 8:51 AM
>>> *To:* Manav Bhatia; Gregory Mirsky
>>> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org;
>>> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org;
>>> rtg-bfd-chairs@ietf.org
>>>
>>> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
>>>
>>>
>>>
>>> I agree with Manav, and nothing in RFC7130 seems to preclude using
>>> different unicast IP address as destination on different member links.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Reshad (as individual contributor).
>>>
>>>
>>>
>>> *From: *Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Manav Bhatia <
>>> manavbhatia@gmail.com>
>>> *Date: *Friday, April 8, 2016 at 11:04 AM
>>> *To: *Gregory Mirsky <gregory.mirsky@ericsson.com>
>>> *Cc: *"draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" <
>>> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" <
>>> mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Alia
>>> Atlas (akatlas@gmail.com)" <akatlas@gmail.com>, "rtg-bfd@ietf.org" <
>>> rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
>>> *Subject: *Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
>>>
>>>
>>>
>>> Hi Greg,
>>>
>>>
>>>
>>> Why cant different micro-BFD packets use the IP address of the MC-LAG
>>> end points? Ones going to router 1 will all carry the same unicast IP
>>> address. The ones going towards the other router will all carry some other
>>> IP address, which would be configured along with the MC-LAG configs.
>>>
>>>
>>>
>>> In fact i would argue that the u-bfd packets going to different routers
>>> must use different IP addresses so that you can actually verify the data
>>> plane liveliness. Whats the point in sending a contrived IP address if the
>>> path that it takes is different from the other regular packets?
>>>
>>>
>>>
>>> Cheers, Manav
>>>
>>>
>>>
>>> On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <
>>> gregory.mirsky@ericsson.com> wrote:
>>>
>>> Hi Manav,
>>>
>>> thank you for sharing insight view of discussions around RFC 7130,
>>> extremely helpful.
>>>
>>> We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents
>>> different case and the compromise that you’ve pointed too is justified. We
>>> will add more details on the potential differences between unicast and
>>> multicast fast paths in the next update.
>>>
>>> We are open to the discussion and always welcome comments and
>>> alternative proposals.
>>>
>>>
>>>
>>>                 Regards,
>>>
>>>                                 Greg
>>>
>>>
>>>
>>> *From:* Manav Bhatia [mailto:manavbhatia@gmail.com]
>>> *Sent:* Thursday, April 07, 2016 7:39 PM
>>> *To:* Mach Chen
>>> *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org;
>>> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org;
>>> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
>>> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
>>>
>>>
>>>
>>> I believe it had to do with multicast datapath (especially link local)
>>> being different from the unicast datapath in most routers. Using link local
>>> multicast IP addresses may not necessarily guarantee Unicast IP
>>> reachability.
>>>
>>>
>>>
>>> When writing 7130 we spent quite a bit of time ensuring that we dont
>>> carve out a special data path for the micro-BFD packets. Using link local
>>> would have made it a lot simpler.
>>>
>>>
>>>
>>> And this is where i think the current proposal is flawed -- they use
>>> link local multicast to ensure IP unicast reachability which is incorrect.
>>>
>>>
>>>
>>> Cheers, Manav
>>>
>>>
>>>
>>> On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen <mach.chen@huawei.com> wrote:
>>>
>>> Hi Greg and all,
>>>
>>>
>>>
>>> I just have quick review on the drafts. If my understanding is correct,
>>> the idea is to use multicast destination address other than unicast address
>>> when  sending BFD packets over LAG links. And actually this idea has been
>>> proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the
>>> predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 did
>>> discuss the idea of using multicast destination address, but for some
>>> reason I forget now(I may need to reiterate the discussions on the
>>> archive), the idea was abandoned, although I still think multicast
>>> destination address is a smart idea.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Mach
>>> ------------------------------
>>>
>>> *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [
>>> gregory.mirsky@ericsson.com]
>>> *Sent:* Tuesday, April 05, 2016 6:16
>>> *To:* rtg-bfd@ietf.org; mpls@ietf.org
>>> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org;
>>> rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (
>>> akatlas@gmail.com)
>>> *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces
>>>
>>> Dear All,
>>>
>>> two new drafts, related to RFC 7130, were published before the meeting:
>>>
>>> ·         BFD on MC-LAG interfaces in IP network
>>> <https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00>
>>>
>>> ·         BFD on MC-LAG interfaces in IP/MPLS network
>>> <https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-mpls-00>
>>>
>>>
>>>
>>> Greatly appreciate your reviews, comments, questions and suggestions.
>>>
>>>
>>>
>>> Regards,
>>>
>>>         Greg
>>>
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>