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.
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
