> From: Roger Jorgensen <rogerj@xxxxxxxxxxxx>
>> a system in which reachability is less ubiquitous? I.e. for a given
>> destination address X, there will be significant parts of the
>> internetwork from which a packet sent to X will not reach X - and not
>> because of access controls which explicitly prevent it, but simply
>> because that part of the internetwork doesn't care to carry routing
>> information for that destination.
> what I read into it is... the future internet might not be structured
> as it is today, we might get a "internet" on the side which don't touch
> the DFZ at all. Mostly regionbased traffic...
Well, that's certainly one structure you could build if you have a system in
which there are "significant parts of the internetwork from which a packet
sent to X will not reach X". Another possibile structure is the kind of thing
that Keith mentioned, with industry-specific sections.
>From a policy standpoint, I don't have any particular feeling about such
designs, pro or con. I mean, if people think it's useful to have them, that's
not my call to make (and in the past I have produced systems which provided
the tools to do exactly that).
>From a technical point of view, I do wonder if it's really worth the effort
required in terms of extra configuration (which is a different point, of
course). Instead of simply flooding information about all destinations
everywhere, now, for each destination which is no longer visible over a
global scope, you basically have to define, via configuration, a boundary
which sets the scope outside which that destination is not 'visible' in the
routing. That's a non-trivial amount of configuration - especially with
today's routing architecture, which has no tools to easy describe/configure
such boundaries.
So if it's simply being done for efficiency reasons, I wonder whether the
complexity/efficiency tradeoff there is worth it. If one has a policy reason
to do it, that changes the equation, of course, and those goals may make it
worthwhile.
(This is all assuming I've correctly understood what he was proposing; the
original message was a little short on technical detail.)
Noel
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf