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.
Ok, two loose usages on my part here: First, by
"available", I meant published in DNS (contrast
"reachable"). Second, DNS may not be accurate. Maybe
third, "complete" might be too strong.
So point taken.
I don't think, however, that this alters my argument.
> 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.
Yes, but I'm missing the point. You seem to be saying
that if things are working, then things are working.
> 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.
Agreed.
>> 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.
Right, but one point about "routing". In most (most)
cases, routing is carrying a prefix that is shorter than
/32 (or /128 if you like). So what routing tells you is
that someone has in the recent past advertised a prefix
covering a destination host's address; it doesn't tell
you whether that destination is up or otherwise
reachable.
> 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
Sure.
> 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.
Again, it is the details of "if a viable one exists" that
is my point.
> [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_.
Sure, but AFAICT this doesn't solve the locator path
liveness problem ("if a viable one exists...").
Good discussion, thnx.
Dave
signature.asc
Description: Digital signature
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
