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