Subject: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017)

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Apr 2017 18:55:40 -0400

Working Group,

https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00
https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/

The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP
and MPLS have requested BFD working group adoption for their drafts.

These drafts were previously presented at IETF-96.

Please note that IPR has been declare against these drafts.  The IPR
declaration may be found from the datatracker links.

Please indicate your support/lack of support to the mailing list.

-- Jeff and Reshad

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 17 Apr 2017 23:39:43 +0000

Jeff and Reshad,

I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01.

The overall problem and proposed solution did not seem to have received much discussion. I was only able to find one email thread on the list, over a year ago.

Regarding the problem statement, it’s strange that there’s no normative definition or anything to MG-LAG… further, the meeting notes from IETF96 say things like:
          John Messenger: Would suggest work done in 802.1 to analyze those
          considerations with 802, it would be necessary to coordinate to work
          with them. Send a mail to IETF-IEEE802 coordination group.
          Jeff Haas: Can we sign you as a reviewer to this draft?

What is the problem again, beyond what’s already well specified in RFC 7130? Is this again a quick “solution” looking for an RFC number?

Regarding the proposed solution, the one email thread seems to have pointed out some serious issues not considered:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/OLWLCf6dn-3zxGZboTKVqUwSr6w
https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7PyJbpP-RVnVFMcQ
https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4UPB4buR0iyxcg
https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAAXyTof4ycq2DUg

Additionally, why the split into two drafts for this? The text of both documents overall seems forgotten, even sloppy, with many typos (“MPSL”, “Indvidual”, etc), and copy/paste text between the two documents. The complete Introduction and Problem Statement are verbatim copy/paste, and include things like:

  This document
   proposes how to overcome this problem if using IP or Multi-Protocol
   Label Switching (MPLS) data plane encapsulation.

which is not the case for either document.

Technically, using multicast here exercises a different path, and using a GAL does as well. What are we testing?

Net-net, do not support.

Thanks,

— Carlos.

On Apr 17, 2017, at 6:55 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

Working Group,

-- Jeff and Reshad

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 18 Apr 2017 07:12:15 +0530

I had raised the exact same concerns when this draft was originally posted.
So I concur with what Carlos says.

Cheers, Manav

--
Sent from a mobile device

On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

Jeff and Reshad,

I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 or
draft-tanmir-rtgwg-bfd-mc-lag-mpls-01.

The overall problem and proposed solution did not seem to have received
much discussion. I was only able to find one email thread on the list, over
a year ago.

Regarding the problem statement, it’s strange that there’s no normative
definition or anything to MG-LAG… further, the meeting notes from IETF96
say things like:
          John Messenger: Would suggest work done in 802.1 to analyze those
          considerations with 802, it would be necessary to coordinate to
work
          with them. Send a mail to IETF-IEEE802 coordination group.
          Jeff Haas: Can we sign you as a reviewer to this draft?

What is the problem again, beyond what’s already well specified in RFC
7130? Is this again a quick “solution” looking for an RFC number?

Regarding the proposed solution, the one email thread seems to have pointed
out some serious issues not considered:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/OLWLCf6dn-3zxGZboTKVqUwSr6w
https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7PyJbpP-RVnVFMcQ
https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4UPB4buR0iyxcg
https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAAXyTof4ycq2DUg

Additionally, why the split into two drafts for this? The text of both
documents overall seems forgotten, even sloppy, with many typos (“MPSL”,
“Indvidual”, etc), and copy/paste text between the two documents. The
complete Introduction and Problem Statement are verbatim copy/paste, and
include things like:

  This document

Technically, using multicast here exercises a different path, and using a
GAL does as well. What are we testing?

Net-net, do not support.

Thanks,

— Carlos.

On Apr 17, 2017, at 6:55 PM, Jeffrey Haas <[email-masked]> wrote:

Working Group,

-- Jeff and Reshad

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 17 Apr 2017 20:17:19 -0700

Hi Manav,
single-hop BFD is helpful when the two BFD peers have Layer 2 switched
domain between them. If the nodes are connected by the single wire, then
there's no apparent benefit of using BFD at all. The same is the case for
these two drafts. BFD is not intended to verify whether forwarding tables
are correlating with the routing tables but it is to verify that a path
exists between the BFD peers. In the case we've considered, the path
through the Layer 2 switched domain. Thus I don't see that traversing the
same blocks in fast path processing on the end nodes of the single-hop IP
link is the critical requirement. But if the working group agrees that it
is, then we'll be glad to work together to confirm with such requirement.

Regards,
Greg

On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia <[email-masked]> wrote:

> I had raised the exact same concerns when this draft was originally
> posted. So I concur with what Carlos says.
>
> Cheers, Manav
>
> --
> I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01
> or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01.
>
> Regarding the proposed solution, the one email thread seems to have
> pointed out some serious issues not considered:

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 18 Apr 2017 09:40:57 +0530

Then BFD is not the right tool. You should use/invent something else.

Cheers, Manav

On Apr 18, 2017 8:47 AM, "Greg Mirsky" <[email-masked]> wrote:

Hi Manav,

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 17 Apr 2017 22:01:53 -0700

Hi Manav,
I agree that it would be helpful to discuss whether using BFD to monitor
Layer 2 connectivity is the right approach. I'd point that from the Layer 2
perspective uBFD is not following the same fast path processing as data
packets either. Thus there could be some scenarios when uBFD produces
either false negative or false positive results. And while we understand
that, we agreed that these are rather exceptions and that uBFD is useful to
monitor constituent links. I believe it is reasonable to have the same
discussion about monitoring constituent links of a MC-LAG. Is it the
problem that needs to be solved? Do these drafts that propose to extend use
of uBFD offer technically reasonable solution? These are the questions, per
my understanding of WG adoption call, that we have in front of us.

Regards,
Greg

On Mon, Apr 17, 2017 at 9:10 PM, Manav Bhatia <[email-masked]> wrote:

>> On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" <
>> [email-masked]> wrote:
>>
>> Jeff and Reshad,
>>

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 18 Apr 2017 21:16:58 +0530

I don't know why you think ubfd packets do not follow the regular data path?

I am traveling and have sporadic Internet connectivity, so response can get
delayed.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 18 Apr 2017 11:55:47 -0700

Hi Manav,
thank you for your consideration. If we agree that what single-hop BFD
effectively monitors is the Layer 2 switched domain, then we should pay
attention to Layer 2 encapsulation. If uBFD implementation uses only the
dedicated MAC address and does not switch to use of source MAC address in
received BFD control packets as described in the first para Section 2.3 RFC
7130, then, I believe, it is possible that processing of L2 frames might be
different whether it carries data or uBFD.

Safe travel and regards,
Greg

On Tue, Apr 18, 2017 at 8:46 AM, Manav Bhatia <[email-masked]> wrote:

> I am traveling and have sporadic Internet connectivity, so response can
> get delayed.
>
> --

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 20 Apr 2017 07:53:03 -0700

Hi Jeff, Reshad, et. al,
support as co-author.

Regards,
Greg