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

[Robert Raszuk <[e-mail]>]

Nick,

If someone is using weak BGP stacks which can not handle two BGP paths per
net .. sorry that to me does not justify inventing new SAFI.

Moreover the idea behind the new SAFI is flawed since it assumes RS always
would have a secondary path to send to client. Otherwise noise of 1000
peers bombarding RS with message "NH-X is not reachable" is pretty useless
if given net has only one NH on the RS.

Moreover those weak clients which can not run best path for RS received
nets are now subject to handle 1000 BFD sessions ... it really does not
sound right that an edge can do the latter just fine and not the former.

Last to address real world problem - I proposed very easy solution which
you as an IXP operator can enable today via simple config on your switch
and treat such switch (or pair of switches) as default forwarder. Done !
Fully backward compatible with existing IXP deployment too.

Thanks,
R.










On Tue, Mar 14, 2017 at 12:30 PM, Nick Hilliard <[e-mail]> wrote:

> Robert,
>
> speaking with my ixp operator hat on:
>
> Robert Raszuk wrote:
> > Any ASBR (even software running in a VM or container) today used as
> > peering router can handle Internet table. That is 600K+ nets.
>
> this statement is incorrect on production networks.
>
> > IXes give you tiny subset of it via open or selective policy.
>
> this statement is incorrect on production ixps.
>
> > Moreover
> > as I mentioned in my original comment - over RS you get local customer
> > and internal routes and no more. So for any net it will be usually one
> > or two paths anyway.
>
> this statement is incorrect on production ixps.
>
> > So if someone has one path (and client has no way of knowing) signalling
> > to RS that next hop is gone is not helpful as there is no backup path RS
> > could recompute and send to such client.
> >
> > Learning two paths for given net with different NHs (even if RS has more
> > then two) seems to provide sufficient robustness and enables you to
> > measure quality to the destinations as well as do things line multipath
> TCP
>
> this statement is both incorrect and wildly unrealistic on real world
> networks, even from the most rarified theoretical point of view.
>
> > Now if someone is really so weak on the edge and attaches to IX to only
> > peer locally we should perhaps invent co-located with RS pair of data
> > plane boxes where such weak guys would for forwarding just default to
> > such data plane gateway. That way those two forwarders could have as
> > many paths as RS feeds it with yet all weak clients are happy to forward
> > and reach all open peers of a given IX.
> >
> > In fact most IX switches while running in L2 mode could be configured
> > for L3 as well so no need to even invest new $$$ needed.
>
> this statement is incorrect at production ixps.
>
> I would be happy to provide multiple counterexamples to all these points.
>
> This draft is attempting to solve a real world problem on real world
> networks.  It would be nice for ixp participants to have ideally
> specified equipment providing service for clients which all had working,
> network-aware multipath implementations which could react immediately to
> blackholing events, but this doesn't even begin to approximate reality.
> Production IXPs need to be able to provide baseline services to a
> hodge-podge of different types of equipment serving the great unwashed
> of the internet.  There are very few assumptions you can make about
> equipment specification that will turn out to be realistic.
>
> Nick
>