Re: Rtg-bfd Digest, Vol 164, Issue 24

[Gyan Mishra <[e-mail]>]

Sent from my iPhone

> On Oct 17, 2019, at 12:20 PM, Albert Fu (BLOOMBERG/ 120 PARK) <[e-mail]> wrote:
> 
> Hi Robert,
> 
> > Dear WG,
> > 
> > Thank you Gyan for your note.
> >
> > It very clearly highlights my primary concern expressed earlier of false
> > assumptions on how engineers may try to (mis)use bfd-large in multihop
> > cases.
> >
> > Below note is a brilliant example of how one may not realize that actual
> > paths BFD packets take can be just a fraction of paths their data plane or
> > even other control plane packets may traverse over a network or set of
> > networks.
> >
> > I am always concerned when protocol extensions being standardized are known
> > to only work in 1 out of 10 deployment scenarios and when chances of such
> > opportunity of incorrect use are evident yet no safety inline fuse exist.
> > 
> > Many thx,
> > Robert.
> 
> As mentioned previously, there are well known cases where BFD can not determine data plane error, and this is not unique to the BFD Large Packet Draft.
> 
> I do not know how other customers use BFD, but can say that in our network, almost all of our BFD use cases are P2P (IGP/eBGP) (and also Control-plane independent), where BFD Large Packet draft will be very useful and deterministic in identifying the issue as it happens.
> 
> Thanks
> Albert
> 
[Gyan] In all the use cases to date working with customer networks my experience has always been for single hop BFD using echo or asynchronous mode used for direct eBGP or ospf or isis p2p links.  I agree my thoughts were that this would be a good tool to help where traditional pmtud may have failed but for the network planner have an idea if IPv6 or any other technology that had a lot of overhead or is built on overlay /underlay technologies.  The only use case for multi hop BFD demand mode is for MVPN P2MP LSP LMDT which is a different animal all together.
>