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

[Manav Bhatia <[e-mail]>]

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

Cheers, Manav

--
Sent from a mobile device

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

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 <[e-mail]> wrote:

> 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)" <[e-mail]>
> 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
>    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 <[e-mail]> wrote:
>
> 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
>
>
>
>
>