Hi Reshad, yes, link local multicast may be used in MC-LAG scenario. The draft states that it MAY be used while the broadcast has SHOULD normative. But we are all open to the discussion. Regards, Greg On Apr 8, 2016 11:28 AM, "Reshad Rahman (rrahman)" <[email protected]> wrote:
> Hi Greg, > > With the proposal in the draft won’t you need a change to indicate that > the link-local multicast address should be used? > > Regards, > Reshad. > > From: Rtg-bfd <[email protected]> on behalf of Gregory Mirsky < > [email protected]> > Date: Friday, April 8, 2016 at 12:12 PM > To: Manav Bhatia <[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 Manav, > > thank you for your consideration. The advantage of the MC-LAG is that > there’s nothing changes for SE which still sees it LAG. If one to use > different destination IP addresses on SE side, then that advantage will be > lost. Our proposal is to preserve it. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:[email protected] <[email protected]>] > > *Sent:* Friday, April 08, 2016 8:05 AM > *To:* Gregory Mirsky > *Cc:* Mach Chen; [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 > > > > 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 > > > > >
