[rrg] Summary of architectural solution space

[Iljitsch van Beijnum]

On 14 nov 2008, at 17:17, William Herrin wrote:

> However, updates due to link changes in the core still
> have to propagate through the entire core, even if the change is so
> distant from the instant router and the topology downstream from the
> instant router is such that the change can't impact the downstream
> FIBs.

Right, the problem with suppressing updates that don't impact the FIB  
is that further upstream (downstream? confusing terminology, just  
credit and debit) the info could impact a FIB there because it's  
combined with other info. However, we could possibly solve this if we  
can let routing info skip routers or AS hops. I.e., if A and B are  
tier 1s and C and D are customers of those, respectively, and E a  
customer of both C and D, C and D could pretty much point a default to  
A cq B, but E would like to know if A loses a link and can now reach  
some destination only through a very long path or not at all, so E may  
want to subscribe to A and B their routing updates even though C and D  
don't care.

> I haven't heard a potentially successful solution strategy that
> addresses this point. I think geoaggregation was the only one that
> attempted it and we proved that geoaggregation has uncorrectable
> theft-of-service anomalies even in small configurations.

The solution is to keep the geo stuff inside a single AS, then these  
issues don't occur.

> The current solution strategies all imply the remaining impact from
> this factor is small enough to be a non-problem.

Famous last words.  :-)

But if we can keep the "core" limited to the actual core then FIB  
scalability shouldn't be an issue, so that only leaves processing  
issues such af flapping and amplification thereof.

> Strategies A and B both depend on aggregated LOC reachability
> information being flooded. It appears to be needed to compute a
> network path.

You can't aggregate reachability info. If a multihomer loses an ISP,  
everyone needs to start sending their traffic through another ISP.  
This is info that can't be aggregated. (Also note that this is only  
relevant for multihomers; for single homed destinations that are in  
the system for other reasons we don't need to know if they're  
reachable.)

> I guess this ties in with your point about suppressing distant routes.
> If you want to suppress distant routes then you can't flood LOC
> reachability info. Is that correct?

You can't but I don't think that's the reason. And you still need to  
know reachability for distant destinations if you actually talk to  
them. However, in the _current_ system we don't care so much about  
updates from distant networks because we can generally assume that any  
repairable failures will be repaired by the time we see the update. In  
other words: if a link in Tokyo dies I'm probably still sending my  
traffic to LA or SF, it's unlikey that I'm now going to circle the  
globe in the opposite direction.

> A1a. Each core ISP has one RLOC. The RLOC's existence and reachability
> is flood-propagated to the rest of the core.

This is problematic because then each ISP still must have full  
customer prefixes in each location. For the largest ISPs just their  
customer prefixes is enough to be problematic, especially when success  
with our effort makes it easier to use EID prefixes.

> A1c. Each core ISP has one aggregated set of RLOCs which it may
> hierarchically assign to customers downstream and/or disaggregate for
> TE. The aggregated RLOC's existance and reachability is
> flood-propagated to the rest of the core.

I guess. Do we really care about the specifics? We just know that the  
number will be larger than 1.


> Assign heirarchically aggregatable LOCs to every host.

Ah, shim6.  :-)

> Suppress distant routes by aggregating them into sets expected to be
> available in a given direction. Because LOC reachability info is not
> flooded, the routing tables each router must deal with are relatively
> small.

If we remove the burden of selecting a working LOC from the routing  
system this can work. We can do this in shim6 and it shouldn't be too  
hard to do with LISP, either. You just need a reachability detection  
protocol. As luck would have it I'm the co-author of one... (shim6- 
failure-detection)

> C1. Geographic aggregation. All nodes within some geographic boundary
> are assigned the same LOC. Routers move packets to any adjacent router
> deemed to be "closer" to the LOC in question.

No, that would be geographic routing. If you think that geographic  
addressing is impossible, think about geographic routing...

The point of geo addressing is that you can point an aggregate in the  
right direction and find the more specific in the place the aggregate  
points to.

> Because even a distant route may present a better priority in one
> coreward direction than another, it's not possible to suppress distant
> routes. As a result, every default-free router in the core must carry
> all routes.

Depends on the topology restrictions you're willing to live with. I  
don't think we need to support the situation where a multihomer  
connects to ISPs in South Africa and Hawaii.

I think the correct constraint is that ISPs must carry their  
customer's prefixes in all their default free routers and other ASes  
must have sufficient routing info to get the packets to a working ISP  
of the destination. (Note that this is harder in the case when A talks  
to B where B has ISPs C and D and A points to C but then the link from  
C to B fails and C is not prepared to route traffic from A to B  
through D.)

Iljitsch

PS. Is fuel now so expensive that a flight leaving at 1530 and  
arriving at 1750, so flying during day time / evening has the lights  
turned off pretty much the whole flight? Good thing these new MacBooks  
have the illuminated keyboard.