v6 deagg

William Herrin bill at herrin.us
Wed Feb 25 00:35:03 UTC 2015


On Tue, Feb 24, 2015 at 1:16 PM, Sander Steffann <sander at steffann.nl> wrote:
> Bill Herrin said:
>> I don't fully understand the math yet but the algorithm doesn't smell
>> right. As near as I can figure it may only be correct in a static
>> system. If after convergence the disaggregate ceases to be reachable
>> from the aggregate, there doesn't appear to be either enough
>> information in the system or enough triggers traveling between routers
>> for it to reconverge to a correct state.
>
> If a network announces an aggregate when they can't reach all
> more-specifics then things will already be broken. Don't announce
> address space that you can't handle traffic for...

Howdy,

That's... basically the opposite of how customer cutout routes work
today. Funny thing about customers... when they go to the trouble of
announcing a route to another ISP, they expect it to work even when
the link to you fails. Not sure where they came up with such an
unreasonable expectation. ;)


Anyway, I heard back from DRAGON's authors. Paraphrasing:

"An aggregate (e.g. 10.0.0.0/8) must be withdrawn if the aggregate's
origin loses its direct route to the filterable disaggregate's origin
(e.g. 10.2.3.0/24). The withdrawn aggregate is replaced with a
synthesized set of announcements which fully cover the aggregate's
address space excluding the unreachable disaggregate (e.g.
10.0.0.0/15, 10.2.0.0/23, 10.2.2.0/24, 10.2.4.0/22, 10.2.8.0/21,
10.2.16.0/20, etc.) When direct connectivity is restored, the
aggregate is again announced and the synthetic announcements
withdrawn."

This overcomes my objection. The aggregate's origin can reasonably be
programmed to trigger on the nearby disaggregate's withdrawal.
System-wide withdrawal of the aggregate route is a sufficient trigger
to cancel filtering on the disaggregate which should then fully
propagate. And the overall savings should still be substantial even
with transient synthetics in the table.

I look forward to seeing how the authors address the many implications
of this requirement. I'm not sold just yet but I am suitably
impressed.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>



More information about the NANOG mailing list