Re: Rtg-bfd Digest, Vol 163, Issue 25

["Albert Fu (BLOOMBERG/ 120 PARK)" <[e-mail]>]

Hi Robert,


> 
> Thank you for sharing the experience and your use case. 

> However when we make any protocol extension we need to make sure all possible deployment cases are covered
> and it must be well understood how the proposed extension will operate in basic deployment scenarios I 
> enumerated. I really do not think we should be standardizing extension for single use case based on the behavior 
> someone is reporting as "likely to occur".

> We all agree that if you have a p2p fiber link between routers there is no issue. 

> The issue surface when you are using emulated circuits as your p2p links. So the solution should allow to detect
> the problem in all cases it can happen. Perhaps BFD is not the right tool for this. Perhaps we need to go back to 
> BESS WG and report that VPWS or EVPN based p2p emulated circuits were not design right as they exhibit observed
> issues. 

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.


> 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 ? 

We have not encountered the issue that you are highlighting. I feel it is a theoretical issue in regards to the problems we have seen, and would rather focus on the real issue. If what you are saying does prove to be true, we can start investing energy on it. 

The thing I like about the BFD Large Packet draft (apart from addressing a known issue we have been facing), is that it does not make any assumption about the underlying network. It could be used to detect hardware issue, device MTU being changed due to power outage, or MTU configuration error. 


> Kind regards,
> Robert.

Thanks
Albert