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

From: Gregory Mirsky <[email-masked]>
Date: Mon, 4 Apr 2016 22:16:07 +0000

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 4 Apr 2016 19:23:05 -0300

Working Group,

These documents reasonably extend the existing BFD on LAG mechanism and would be reasonably in charter for BFD to pick up.

Greg, given that adoption seems a reasonable course, could you and the other co-authors state whether there's any known IPR on these documents?

-- Jeff

> On Apr 4, 2016, at 7:16 PM, Gregory Mirsky <[email-masked]> wrote:
> 
> Dear All,
> ·         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>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 4 Apr 2016 22:31:30 +0000

Hi Jeff,
we have not expected this question that early ☺
Yes, there’s IPR associated with these drafts that would be properly disclosed after the meeting.

                Regards,
                                Greg

From: Jeffrey Haas [mailto:[email-masked]]
Sent: Monday, April 04, 2016 3:23 PM
To: Gregory Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Alia Atlas ([email-masked])
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Working Group,

-- Jeff

On Apr 4, 2016, at 7:16 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

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>

Regards,
        Greg

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 4 Apr 2016 22:44:28 +0000

Hi Jeff,

Thanks!

IPR will be disclosed ASAP, we are pushing legal.

Regards,
Jeff

On Apr 4, 2016, at 7:31 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeff,
we have not expected this question that early :)
Yes, there’s IPR associated with these drafts that would be properly disclosed after the meeting.

                Regards,
                                Greg

From: Jeffrey Haas [mailto:[email-masked]]
Sent: Monday, April 04, 2016 3:23 PM
To: Gregory Mirsky
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alia Atlas ([email-masked]<mailto:[email-masked]>)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Working Group,

-- Jeff

Dear All,

Regards,
        Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 5 Apr 2016 09:33:52 -0400

Greg (and Jeff T.):

> Yes, there’s IPR associated with these drafts that would be properly disclosed after the meeting.

The ADs have been prodding us extra hard about IPR recently. :-)  A relevant
section from BCP 79:

: 6.2.2.  Timing of Disclosure Under Section 6.1.2
: 
:    The IPR disclosure required pursuant to section 6.1.2 must be made as
:    soon as reasonably possible after the Contribution is published in an
:    Internet Draft or RFC, unless the required disclosure is already on
:    file.  Participants who realize that the IPR will be or has been
:    incorporated into a submission to be published in an Internet Draft,
:    or is seriously being discussed in a working group, are strongly
:    encouraged to make at least a preliminary disclosure.  That
:    disclosure should be made as soon after coming to the realization as
:    reasonably possible, not waiting until the document is actually
:    posted or ready for posting.

Thus it's okay to just note on the mailing list that you're aware of IPR and
that a formal declaration should be getting filed at some point in the
future.

-- Jeff

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 6 Apr 2016 16:18:46 -0400

IMHO, WG should wait till IPR are disclosed and reviewed before making progress on these drafts.

Thanks,
Himanshu

From: mpls [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Monday, April 04, 2016 6:44 PM
To: Gregory Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Jeff,

Thanks!

Regards,
Jeff

On Apr 4, 2016, at 7:31 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jeff,
we have not expected this question that early :)
Yes, there's IPR associated with these drafts that would be properly disclosed after the meeting.

                Regards,
                                Greg

Working Group,

-- Jeff

Dear All,

Regards,
        Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 6 Apr 2016 22:40:08 +0000

Hi Himanshu,
the IPR Disclosures should be published in a day or two. In the meantime, what in particular you suggest the WG should look into - importance of the problem, terms of the Disclosures or claims of the invention?

                Regards,
                                Greg

From: Shah, Himanshu [mailto:[email-masked]]
Sent: Wednesday, April 06, 2016 1:19 PM
To: Jeff Tantsura; Gregory Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

Thanks,
Himanshu

From: mpls [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Monday, April 04, 2016 6:44 PM
To: Gregory Mirsky
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Jeff,

Thanks!

Regards,
Jeff

                Regards,
                                Greg

Working Group,

-- Jeff

Dear All,

Regards,
        Greg

---

From: Mach Chen <[email-masked]>
Date: Thu, 7 Apr 2016 17:46:46 +0000

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-masked]] on behalf of Gregory Mirsky [[email-masked]]
Sent: Tuesday, April 05, 2016 6:16
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Alia Atlas ([email-masked])
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces

Dear All,

Regards,
        Greg

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 8 Apr 2016 08:08:40 +0530

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-masked]> 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-masked]] on behalf of Gregory Mirsky [
> [email-masked]]
> *Sent:* Tuesday, April 05, 2016 6:16
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked];
> [email-masked]; [email-masked]; Alia Atlas (
> [email-masked])
> *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces
>
> Dear All,
>
> ·         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>
>
>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 8 Apr 2016 12:39:14 +0000

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-masked]]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Alia Atlas ([email-masked])
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-masked]<mailto:[email-masked]>> wrote:

Hi Greg and all,

Best regards,

Mach

________________________________
From: Rtg-bfd [[email-masked]<mailto:[email-masked]>] on behalf of Gregory Mirsky [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, April 05, 2016 6:16
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alia Atlas ([email-masked]<mailto:[email-masked]>)
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:

Regards,
        Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 8 Apr 2016 12:42:45 +0000

Hi Mach,
many thanks for your review and the reference. Will study it in details. Will be glad to continue this work with you. Would you consider joining the authors?

                Regards,
                                Greg

From: Mach Chen [mailto:[email-masked]]
Sent: Thursday, April 07, 2016 10:47 AM
To: Gregory Mirsky; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Alia Atlas ([email-masked])
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Greg and all,

Best regards,

Mach

Regards,
        Greg

---

From: Mach Chen <[email-masked]>
Date: Fri, 8 Apr 2016 14:14:28 +0000

Hi Greg,

Thanks for the invitation, I am glad to join and continue the work.

Best regards,

Mach

________________________________
From: Gregory Mirsky [[email-masked]]
Sent: Friday, April 08, 2016 20:42
To: Mach Chen; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Alia Atlas ([email-masked])
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Mach,

                Regards,
                                Greg

Hi Greg and all,

Best regards,

Mach

Regards,
        Greg

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 8 Apr 2016 20:34:45 +0530

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-masked]>
wrote:

> 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.
>
> *From:* Manav Bhatia [mailto:[email-masked]]
> *Sent:* Thursday, April 07, 2016 7:39 PM
> *To:* Mach Chen
> *Cc:* Gregory Mirsky; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; Alia Atlas ([email-masked])
> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
>
>
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 8 Apr 2016 15:50:47 +0000

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-masked]<mailto:[email-masked]>> on behalf of Manav Bhatia <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Alia Atlas ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alia Atlas ([email-masked]<mailto:[email-masked]>)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Cheers, Manav

Hi Greg and all,

Best regards,

Mach

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

Regards,
        Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 8 Apr 2016 16:12:17 +0000

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-masked]]
Sent: Friday, April 08, 2016 8:05 AM
To: Gregory Mirsky
Cc: Mach Chen; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Alia Atlas ([email-masked])
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Greg,

Cheers, Manav

                Regards,
                                Greg

Cheers, Manav

Hi Greg and all,

Best regards,

Mach

Regards,
        Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 8 Apr 2016 16:14:13 +0000

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-masked]]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; Alia Atlas ([email-masked]); [email-masked]; [email-masked]
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Regards,

Hi Greg,

Cheers, Manav

                Regards,
                                Greg

Cheers, Manav

Hi Greg and all,

Best regards,

Mach

Regards,
        Greg

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 8 Apr 2016 16:28:27 +0000

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-masked]<mailto:[email-masked]>> on behalf of Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 8, 2016 at 12:12 PM
To: Manav Bhatia <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Alia Atlas ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Manav,

                Regards,
                                Greg

From: Manav Bhatia [mailto:[email-masked]]
Sent: Friday, April 08, 2016 8:05 AM
To: Gregory Mirsky
Cc: Mach Chen; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alia Atlas ([email-masked]<mailto:[email-masked]>)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Greg,

Cheers, Manav

                Regards,
                                Greg

Cheers, Manav

Hi Greg and all,

Best regards,

Mach

Regards,
        Greg

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 8 Apr 2016 23:03:59 +0530

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-masked]>
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-masked]]
> *Sent:* Friday, April 08, 2016 8:51 AM
> *To:* Manav Bhatia; Gregory Mirsky
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; Alia Atlas ([email-masked]); [email-masked];
> [email-masked]
>
> I agree with Manav, and nothing in RFC7130 seems to preclude using
> different unicast IP address as destination on different member links.
>
>
>
> Regards,
>
> *From: *Rtg-bfd <[email-masked]> on behalf of Manav Bhatia <
> [email-masked]>
> *Date: *Friday, April 8, 2016 at 11:04 AM
> *To: *Gregory Mirsky <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "Alia
> Atlas ([email-masked])" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
>
>
>
> Hi Greg,
>
>
>
> On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <
> [email-masked]> wrote:
>
> Hi Manav,
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 8 Apr 2016 11:43:18 -0700

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-masked]>
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-masked]> on behalf of Gregory Mirsky <
> [email-masked]>
> To: Manav Bhatia <[email-masked]>
> Cc: "[email-masked]" <
> 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-masked] <[email-masked]>]
>
> *Sent:* Friday, April 08, 2016 8:05 AM
> *To:* Gregory Mirsky
> *Cc:* Mach Chen; [email-masked]; [email-masked];

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 8 Apr 2016 12:01:03 -0700

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-masked]> 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?
>
> On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky <
>> 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.
>>
>>
>>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Manav Bhatia <[email-masked]>
Date: Sat, 9 Apr 2016 06:07:31 +0530

Hi Greg,

> or both with appropriate normative language. But I would not agree that

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

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 9 Apr 2016 04:16:23 +0000

Hi Manav,
the use case for the BFD over MC-LAG interfaces that I consider the most important for this drafts to address is to enable sub-second defect detection in order to trigger LACP convergence and, subsequently, switchover within the Redundancy Group in Active-Standby case. Hence both unicast and multicast L3 addresses are quite distant from L2 fast path and processing usually taken by CCM frames. Of course, one can use CFM per LAG Constituent Link, and I have implemented that and it interoperates with another implementation by other vendor, but operators prefer ease of BFD provisioning. Thus I’ve to provide them with ability to monitor MC-LAG and explain that in some cases it may produce false negative when L2 is functional and the problem is in L3, unicast or multicast, engine. As you can see, there’s not much value in continuing argument how much different L3 multicast processing is from L3 unicast as both are different from L2 path. At the end, as I think, it is up to operators to decide whether they are comfortable with this mechanism or would require defect detection at L2.

                Regards,
                                Greg

From: Manav Bhatia [mailto:[email-masked]]
Sent: Friday, April 08, 2016 5:38 PM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Gregory Mirsky
Subject: 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.

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" <[email-masked]<mailto:[email-masked]>> 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?

Cheers, Manav

On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alia Atlas ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Regards,

Hi Greg,

Cheers, Manav

                Regards,
                                Greg

Cheers, Manav

Hi Greg and all,

Best regards,

Mach

Regards,
        Greg

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Manav Bhatia <[email-masked]>
Date: Sat, 9 Apr 2016 14:38:20 +0530

Hi Greg,

There is a difference, a big one.

When you use CFM or some other L2 OAM protocol, you dont make any claims
about L3 connectivity. However, when you start using BFD it implicitly
means that youre talking about L3 connectivity. So, its going to be bizarre
debugging complex topologies where BFD sessions never flap and yet MPLS
LSPs randomly time out (because there is this one MC-LAG thats dropping
packets -- and in the worst case, only sporadically and intermittently
drops IP packets)

It will NOT produce false negatives (as you claim) but rather introduce
false positives, which is more dangerous. The MC-LAG will be up, while it
would be dropping all or few IP packets.

I have no objections if operators and the community think that this is
something that they can live with. I am personally having an out-of-body
experience just discussing this! :-)

Cheers, Manav

On Sat, Apr 9, 2016 at 9:46 AM, Gregory Mirsky <[email-masked]>
wrote:

> Hi Manav,
>
> the use case for the BFD over MC-LAG interfaces that I consider the most
> important for this drafts to address is to enable sub-second defect
> detection in order to trigger LACP convergence and, subsequently,
> switchover within the Redundancy Group in Active-Standby case. Hence both
> unicast and multicast L3 addresses are quite distant from L2 fast path and
> processing usually taken by CCM frames. Of course, one can use CFM per LAG
> Constituent Link, and I have implemented that and it interoperates with
> another implementation by other vendor, but operators prefer ease of BFD
> provisioning. Thus I’ve to provide them with ability to monitor MC-LAG and
> explain that in some cases it may produce false negative when L2 is
> functional and the problem is in L3, unicast or multicast, engine. As you
> can see, there’s not much value in continuing argument how much different
> L3 multicast processing is from L3 unicast as both are different from L2
> path. At the end, as I think, it is up to operators to decide whether they
> are comfortable with this mechanism or would require defect detection at L2.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *Sent:* Friday, April 08, 2016 5:38 PM
> *To:* Greg Mirsky
> *Cc:* Reshad Rahman (rrahman);
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; Gregory
> Mirsky
> *Subject:* 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.
>
>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 9 Apr 2016 22:32:48 +0000

Hi Manav,
I’m glad that we’re converging – the final decision would come from our customers, the operators.
I hope we’ll have their comments.
In the meantime, I invite you and other experts to review the second draft that looks into the same scenario but over the IP/MPLS network. It may be less controversial as neither multicast, nor broadcast addresses need to be used as the destination IP address.

                Regards,
                                Greg

From: Manav Bhatia [mailto:[email-masked]]
Sent: Saturday, April 09, 2016 2:08 AM
To: Gregory Mirsky
Cc: Greg Mirsky; Reshad Rahman (rrahman); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Greg,

When you use CFM or some other L2 OAM protocol, you dont make any claims about L3 connectivity. However, when you start using BFD it implicitly means that youre talking about L3 connectivity. So, its going to be bizarre debugging complex topologies where BFD sessions never flap and yet MPLS LSPs randomly time out (because there is this one MC-LAG thats dropping packets -- and in the worst case, only sporadically and intermittently drops IP packets)

It will NOT produce false negatives (as you claim) but rather introduce false positives, which is more dangerous. The MC-LAG will be up, while it would be dropping all or few IP packets.

I have no objections if operators and the community think that this is something that they can live with. I am personally having an out-of-body experience just discussing this! :-)

Cheers, Manav

On Sat, Apr 9, 2016 at 9:46 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Manav,
the use case for the BFD over MC-LAG interfaces that I consider the most important for this drafts to address is to enable sub-second defect detection in order to trigger LACP convergence and, subsequently, switchover within the Redundancy Group in Active-Standby case. Hence both unicast and multicast L3 addresses are quite distant from L2 fast path and processing usually taken by CCM frames. Of course, one can use CFM per LAG Constituent Link, and I have implemented that and it interoperates with another implementation by other vendor, but operators prefer ease of BFD provisioning. Thus I’ve to provide them with ability to monitor MC-LAG and explain that in some cases it may produce false negative when L2 is functional and the problem is in L3, unicast or multicast, engine. As you can see, there’s not much value in continuing argument how much different L3 multicast processing is from L3 unicast as both are different from L2 path. At the end, as I think, it is up to operators to decide whether they are comfortable with this mechanism or would require defect detection at L2.

                Regards,
                                Greg

From: Manav Bhatia [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, April 08, 2016 5:38 PM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Gregory Mirsky
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Greg,

Cheers, Manav

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 11 Apr 2016 13:23:32 -0400

Greg,

This is more of a general comment on discussions from the development from
RFC 7130 than any specific comment on your draft.  

> all open to the discussion.

During our discussions across multiple vendors, including some hardware
vendors, it was determined that attempts to exercise the layer 3 mechanisms
would vary significantly across implementations depending on how packets
were encapsulated.  Multicast in particular provided some problematic issues
for us beyond the initial bootstrapping phase of LAG for BFD wherein we
might not have ARP completed.  

My recommendation is to proceed with your drafts with similar caution.  Try
to stay as true to pure IP as possible to best insure the L3 data paths are
exercised across implementations from various vendors.

-- Jeff (speaking as an individual contributor)

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 12 Apr 2016 22:48:40 +0000

Hi Jeff,

thank you for adding more details to the discussions before RFC 7130. We have submitted another draft that proposes to use MPLS encapsulation of BFD control packets over MC-LAG interfaces. Would greatly appreciate reviews, questions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls<https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-mpls-00>.

                Regards,

                                Greg

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Monday, April 11, 2016 10:24 AM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman); [email-masked]; [email-masked]; [email-masked]; Alia Atlas ([email-masked]); [email-masked]; [email-masked]
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Greg,

This is more of a general comment on discussions from the development from RFC 7130 than any specific comment on your draft.

On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote:

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

During our discussions across multiple vendors, including some hardware vendors, it was determined that attempts to exercise the layer 3 mechanisms would vary significantly across implementations depending on how packets were encapsulated.  Multicast in particular provided some problematic issues for us beyond the initial bootstrapping phase of LAG for BFD wherein we might not have ARP completed.

My recommendation is to proceed with your drafts with similar caution.  Try to stay as true to pure IP as possible to best insure the L3 data paths are exercised across implementations from various vendors.

---

From: Glen Kent <[email-masked]>
Date: Wed, 13 Apr 2016 18:38:15 +0530

Gregory,

You are using a special GAL label for BFD packets. This label exists only
for the BFD packets.

How can you then claim connectivity for other traffic which will not use
this label?

Glen

On Wed, Apr 13, 2016 at 4:18 AM, Gregory Mirsky <[email-masked]

> Hi Jeff,
>
> thank you for adding more details to the discussions before RFC 7130. We
> have submitted another draft that proposes to use MPLS encapsulation of BFD
> control packets over MC-LAG interfaces. Would greatly appreciate reviews,
> questions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls
> <https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-mpls-00>.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> Cc: Reshad Rahman (rrahman);
> [email-masked]; [email-masked];
> were encapsulated.  Multicast in particular provided some problematic
> issues for us beyond the initial bootstrapping phase of LAG for BFD wherein
> we might not have ARP completed.
>
>
>
> My recommendation is to proceed with your drafts with similar caution.
> Try to stay as true to pure IP as possible to best insure the L3 data paths
> are exercised across implementations from various vendors.
>
>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 13 Apr 2016 15:49:21 +0000

Hi Glen,
thank you for your question. I would not say that GAL label “exists only for the BFD packets”. This special purpose label can be used in infinite number of scenarios, including MC-LAG environment. But I agree, as in the draft-tanmir-rtgwg-bfd-mc-lag-ip, we make certain assumptions about the forwarding engines and whether proper processing of MPLS encapsulated packet may be interpreted as indication of properly functioning Layer 2 and/or Layer 3. Or, what may more important for monitoring link layer, failure detected with MPLS encapsulation may be interpreted as indication of a defect in Layer 2 and/or Layer 3.

                Regards,
                                Greg

From: Glen Kent [mailto:[email-masked]]
Sent: Wednesday, April 13, 2016 6:08 AM
To: Gregory Mirsky
Cc: Jeffrey Haas; Greg Mirsky; [email-masked]; [email-masked]; [email-masked]; Alia Atlas ([email-masked]); Reshad Rahman (rrahman); [email-masked]; [email-masked]
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Gregory,

You are using a special GAL label for BFD packets. This label exists only for the BFD packets.

How can you then claim connectivity for other traffic which will not use this label?

Glen

On Wed, Apr 13, 2016 at 4:18 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeff,

                Regards,

                                Greg

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, April 11, 2016 10:24 AM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alia Atlas ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

Greg,