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 protected]> 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)" <[email protected]> > 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 <[email protected]> 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 > > > > >
