Re: [babel] Martin Duke's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS)

[Martin Duke <[e-mail]>]

Sorry, I overlooked these replies in my email. I will remove my DISCUSS.

On Thu, Nov 5, 2020 at 8:25 AM Juliusz Chroboczek <[e-mail]> wrote:

> I've done some minor reordering to your comments.  Hopefully this doesn't
> change their meaning.
>
> > I am concerned about the congestion implications of this architecture.
> If there
> > are P prefixes in the network, the number of TLVs exchanged potentially
> goes
> > from P to P^2.
>
> Source-specific routes don't arise ex nihilo: they are injected into the
> routing domain through redistribution, just like ordinary, destination-only
> routes.  There is no way for Babel to exchange P² prefixes unless the
> network administrator has explicitly selected P² prefixes for
> redistribution.
>
> > But are there any safeguards in the protocol against this happening
>
> There are no safeguards in the protocol against a network administrator
> redistributing unreasonable numbers of source-specific routes into a Babel
> domain, just like there are no safeguards in the protocol against
> redistributing the full BGP routing table.
>
> > Or ought there to be some operational guidance to be somewhat selective
> > about source prefixes?
>
> Source-specific routing is a mechanism, which, as you rightly note, has
> a worst-case quadratic cost.  We currently know of three applications for
> source-specific routing, outlined in [SS-ROUTING] Sections II.B and II.C,
> and none of the three known applications lead to the worst-case quadratic
> explosion that you fear.  Interestingly, two of these applications have
> the potential to reduce the amount of routing data propagated globally in
> the Internet, at a moderate cost in the amount of data propagated locally.
> This seems to me like an excellent tradeoff.
>
> As source-specific routing becomes widely available and well-known, people
> will hopefully find new and exciting applications for this mechanism.
> Each of these new applications will need to be studied carefully, and its
> complexity understood.  It is not the role of the mechanism, however, to
> prohibit future applications just because they might turn out to be too
> costly.
>
> -- Juliusz
>