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

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 04 Nov 2020 17:24:22 -0800

Martin Duke has entered the following ballot position for
draft-ietf-babel-source-specific-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.

Perhaps this is an unrealistic use case. But are there any safeguards in the
protocol against this happening (e.g. limitations on size/freq of updates?) Or
ought there to be some operational guidance to be somewhat selective about
source prefixes?

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 05 Nov 2020 12:53:15 +0100

> https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/

The way it's been used in deployments that I'm aware of, generally only
default routes are distributed with a source prefix, and more specific
routes internally to the network do not have source prefixes. See my
reply to Alvaro for a fuller example:

https://mailarchive.ietf.org/arch/msg/babel/7_O-b6bN525EonbZu0cf6_hIjKU/

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 05 Nov 2020 17:25:53 +0100

I've done some minor reordering to your comments.  Hopefully this doesn't
change their meaning.

> are P prefixes in the network, the number of TLVs exchanged potentially goes

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