v6 deagg

Thu Feb 26 19:51:17 UTC 2015

On 2/24/2015 6:35 PM, William Herrin wrote:
> 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 

Yipee for huge amounts of automatic updates! I guess convergence latency 
is better than memory?

So, how many /16 networks does a core network have which they hand out 
to customers that are multi-homed? What is the state of flux? Normally, 
we'd see the transition states of the more specific routes. Now we'll 
see multiple updates for each of those transition states (/24 removed so 
/16 is broken. Another /24 is removed so a /17 is broken, another /24 is 
removed so a /18 is broken). Provider X lost 50 multihomed customers 
spread across 20 aggregate networks. Process!

Aggregates normally cover unassigned space as well. Do we now have to 
define to the router which space is supposed to be used and which is not 
so it knows when to break apart an aggregate?

Removing a route "don't come this way!" is roughly the same as breaking 
the aggregate except for the extra processing time. It is likely that a 
node choosing between 2 aggregates would also be choosing the same 
between 2 more specific routes. Until convergence is done, it'd still 
route the wrong way in either case. One could stipulate that convergence 
might be slightly longer in this case due to update processing.

Routing might be contrary to desire in cases where more specific route 
is advertised one way only and then an aggregate is used as a fallback. 
While the node filtering the more specific route may consider the path 
the same so it filters, the next node is making a choice between 
aggregates and may choose to send the traffic the other way because it's 
less AS hops; but don't worry, the 256k line backup will do just fine!

Consider this simplistic model:

A------B
  \    /
    C

C is a business or ISP with it's own address space. It normally 
advertises an aggregate /20 to A and B. A and B local-pref C's routes 
because that's what transit providers do. C is under a DDOS attack. They 
issue a covering /24 to B and a /32 to B for blackhole service. B will 
propagate the /32 through it's entire network because the hop is to a 
discard (nifty!), however, the /24 will be the same as the /20, so it is 
filtered out. We can change the local-pref (go communities) of the /24 
and that will allow it to propagate to A. A will accept the /24, 
presumably because the /24 doesn't match the selected /20 chosen 
(because of local pref).

However!

A--D---B
  \    /
    C

D may or may not filter the /24 from B. It depends on their routing 
policy. A may only see the /20 from D and thus send all it's DDOS 
traffic on to C due to local-pref. Sorry, C. Next time, please manually 
change your BGP so you no longer advertise an aggregate. Oh, and it will 
be simpler for you to change if you just do /24 networks from now on and 
don't bother with the aggregate headache.

SUMMARY:

What is the cost if aggregates start being broke apart and not used 
because people want to insure their traffic does what they want?

What is the cost of all these aggregate networks being broken up because 
their more specific routes aren't there?

What is the cost of managing which smaller networks are supposed to be 
there and which are just unassigned currently to prevent aggregate breakup?

Jack

P.S. I didn't delve completely into all the documents and so perhaps I 
misunderstood or missed something important. My concerns may be 
completely unjustified.