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. -- Sent from a mobile device On Apr 18, 2017 10:31 AM, "Greg Mirsky" <[email protected]> wrote: > 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 protected]> > wrote: > >> 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" <[email protected]> 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 <[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-3zxG >>> ZboTKVqUwSr6w >>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7Py >>> JbpP-RVnVFMcQ >>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4 >>> UPB4buR0iyxcg >>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAA >>> XyTof4ycq2DUg >>> >>> 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 >>> >>> >>> >>> >>> >> >> >
