Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

[Robert Raszuk <[e-mail]>]

Nick,

I am very happy for you that your experience with published static MTU
values is so great. Well if you go via your own switches with dark fiber I
would not expect this to be any different.

If however you operate a distributed IX and use leased circuits from other
carriers between your access switches you may be very surprised that
suddenly your MTU get's reduced due to underlying carrier reroute to
different links or applying say MPLS link protection.

We do see this occurring more and more these days and it is nasty to
troubleshoot too if you have no proper tool running. So tactfully I
recommend we do not close our minds to only those problems which one have
seen in his own shop.

On the topic of ICMP or ARP it is your choice. I prefer to know that my
upstream is down in say 2 sec rather then suffer from broken Internet link
forever as my upstream provider will not run BFD session with an office
fiber tail.

Cheers,
R.



On Thu, Apr 20, 2017 at 1:31 PM, Nick Hilliard <[e-mail]> wrote:

> Robert Raszuk wrote:
> > And one of the requirements as you have heard from at least one customer
> is
> > to test MTU of the path to such BGP next hops. Is RFC5880 BFD really best
> > tool for that ?
>
> All IXPs have published MTUs and someone attempts to connect to an IXP
> with the expectation that using a different MTU is going to cause
> anything other than complete brokenness, then I'd tactfully suggest an
> alternative career path.
>
> >     As noted previously, the draft does permit for alternate means
> >     beyond BFD.
> >     However, we have to pick one.  Standardizing ping is likely a bad
> >     idea. :-)
> >
> > ​What is there to standardize ? RFC862 seems like pretty good standard
> > already.
>
> With sufficient thrust, pigs fly just fine.
>
> ICMP is the wrong tool in the same way that ARP request/reply is also
> the wrong tool for this.  It's rubbish for this purpose because it's
> usually highly deprioritised on routers, unlike bfd which is often
> fast-pathed and carefully controlled.  BFD is fit for this purpose
> because it's designed specifically and is supported by router vendors
> for exactly this purpose.
>
> Fast liveliness detection cannot be pawned off to an arbitrary protocol
> just because that protocol replies to packets, in the same way that we
> don't exchange routes over xml in https or implement ssh using udp/53,
> or plough fields using a modified toyota yaris.
>
> Nick
>