On Tue, Oct 01, 2019 at 11:11:13PM -0000, Albert Fu (BLOOMBERG/ 120 PARK) wrote: > There are well known cases, including those you mentioned, where BFD has > limitations in deterministically detecting data plane issue, and not > specific with the BFD Large Packet Draft. I am a novice to the IETF > process, and not sure if we need to mention them here, but shall discuss > with Jeff if it is worth highlighting them.
It's reasonable to make note of issues where common operational scenarios will complicate the solution. But it's not up to a draft carried on top of an RFC with that core issue to try to solve the issue in that core RFC. So, trying to solve "BFD doesn't work perfectly in the presence of LAGs" in bfd-large is the wrong place to do it. :-) That said, Robert, there's room for you to work on that if you want to kick off a draft on the topic. > > We won't have control over how the Provider maps our traffic (BFD/data). > > > Well of course you do :) Just imagine if your BFD packets (in set equal to > > configured multiplier) would start > > using random UDP source port which then would be mapped to different ECMP > > buckets along the way in provider's > > underlay ? And that's an example of possible solution space for such a draft on the underlying issue. That said, LAG fan-out issues are a massive operational pain. While it's likely that varying L3 PDU fields for entropy to distribute traffic across the LAG may work (and we have any number of customers who rely on this for UDP especially), it starts getting very problematic when you have multiple LAGs in a path. I have a vague memory that someone had started some discussions with IEEE to try to figure out what OAM mechanisms would look like for such scenarios, but that's very much out of normal BFD scope. -- Jeff
