Hi Manav, 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. Regards, Greg On Apr 8, 2016 12:34 PM, "Manav Bhatia" <[email protected]> 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 < > [email protected]> 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:[email protected]] >> *Sent:* Friday, April 08, 2016 8:51 AM >> *To:* Manav Bhatia; Gregory Mirsky >> *Cc:* [email protected]; [email protected]; >> [email protected]; Alia Atlas ([email protected]); [email protected]; >> [email protected] >> >> *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 <[email protected]> on behalf of Manav Bhatia < >> [email protected]> >> *Date: *Friday, April 8, 2016 at 11:04 AM >> *To: *Gregory Mirsky <[email protected]> >> *Cc: *"[email protected]" < >> [email protected]>, "[email protected]" < >> [email protected]>, "[email protected]" <[email protected]>, "Alia >> Atlas ([email protected])" <[email protected]>, "[email protected]" < >> [email protected]>, "[email protected]" <[email protected]> >> *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 < >> [email protected]> 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:[email protected]] >> *Sent:* Thursday, April 07, 2016 7:39 PM >> *To:* Mach Chen >> *Cc:* Gregory Mirsky; [email protected]; [email protected]; >> [email protected]; [email protected]; >> [email protected]; Alia Atlas ([email protected]) >> *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 <[email protected]> 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 [[email protected]] on behalf of Gregory Mirsky [ >> [email protected]] >> *Sent:* Tuesday, April 05, 2016 6:16 >> *To:* [email protected]; [email protected] >> *Cc:* [email protected]; >> [email protected]; [email protected]; Alia Atlas ( >> [email protected]) >> *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 > [email protected] > https://www.ietf.org/mailman/listinfo/mpls > >
