Dave,
On Dec 9, 2008, at 7:46 AM, David Meyer wrote:
In today's world, hosts have pretty much complete
information about which <source,destination> pairs are
available.
Not to do my Bill Manning imitation, but I suspect this isn't fully
accurate. We have a set of assertions about destinations that may or
may not be accurate at any given point in time, constrained by BGP
propagation delays, IGP convergence, DNS cache expiration, DNS
authoritative updates, etc.
In the steady state, I would agree with your statement. However, in
the steady state, it doesn't matter all that much. Where stuff gets
interesting is when you've got (lots of) transitions. Much (all?) of
the concern regarding locator path liveness in is detecting these
transitions and providing sufficient information to active path
components to make alternative decisions in some reasonable amount of
time. My impression is that one of the drivers behind concerns about
routing system scaling is, in fact, the worry that the time to
converge on an alternative will become unreasonable.
In map-and-encap schemes, the host doesn't know how many
"ways" there are to reach a remote ID (i.e., how many
RLOCs there are, or if they are reachable), so it can't
implement a strategy test reachability to the
correspondent (note that even TCP timeout doesn't help
here, unless there the host finds another EID that maps
to a different RLOC set).
Right, since the host is 'protected' from knowledge of the underlying
topology. Looking at this simplistically, assume you have a locator
routing system that looks like today's routing system and a mapping
system that fetches statically configured EID to (one or more) RLOC
mappings. At any point within the source locator to destination
locator path, routers make decisions based on the destination locator
according to information propagated via BGP. If a BGP update
indicates that the destination locator is no longer available, the
router doing the forwarding has two choices:
1) drop the packet on the floor and wait for someone upstream (e.g.,
the originating ITR) to notice (perhaps after being prodded) and stop
using the bad destination locator
2) pop the encapsulation (keeping the source locator), re-do the
lookup of the destination EID to discover all possible locators, use
information at that router to pick a new destination locator and, if a
viable one exists, re-encapsulate using the new destination locator
and the original source locator.
[waiting while the screams of horror and outrage at choice 2 die down.]
My impression is that efforts on LOC/ID separation have been focused
on the first choice (for valid reasons), however the second choice
more closely mirrors the behavior of the existing routing system in
which every router can make routing decisions based on the destination
_identifier_.
Regards,
-drc
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
