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 > > >
