Robin, > Map-Servers needing to make GRE tunnels to a large > number (hundreds, thousands) of level 1 ALT > aggregation routers - and likewise those routers > needing to make GRE tunnels to large numbers of > Map-Servers.
Actually, those numbers (100s, 1000s) are speculation.
There are many ways folks might deploy this technology
(e.g, with hierarchy of some kind, as one example). So
lets see what how people actually deploy stuff before
speculating on what they might do (and I would strike the
not-so-parenthetical comment from future discussions).
BTW, the RRG (or IETF, or ITU-T, or ATIS, ...) can
specify any technology they want. However, SPs if deploy
it, they will deploy it in the way that makes most
business sense for their particular predicament, and that
may or may not bear any relationship to what is said in
SDO deliberations. And unfortunately, we have precious
little input from those folks our (SDO) fora.
> Two Map-Servers for an end-user network's two ETRs
> will generally link directly (via a GRE tunnel) to
> the same level 1 ALT aggregation router. There,
> the router will (I guess) send packets for this
> network's EID prefix only to one of these, since they
> both have the same AS hop count of 1. Which will
> depend on the AS number of the ISP.
I don't know what level 1 ALT means. The ALT doesn't
carry level identifiers (we thought about this in CONS
but discarded it for various reasons). And again, just
like everything else, you build scalability with
hierarchy. Like every hierarchy, there will be a "top
level", but not everyone will or needs to connect to such
a top level.
> How can an ALT router, such as this busy level 1
> aggregation router, detect the failure or
> unreachability of a Map-Server? I guess it would
> find out when it tries to send a Map-Request message
> to the Map-Server via the GRE tunnel. But is there
> a keepalive arrangement so the level 1 router could
> detect the disappearance of this Map-Server before
> it sends a Map-Request?
>
> More on potential problems with caching Map-Resolvers.
Regarding "upness": You can make the same argument for
BGP peers in the DFZ (or DNS if you like). In the case of
BGP, we use BGP keepalives, BFD (if you like), and the
existence of the route in the RIB/FIB as basically a
bunch of heuristics, which work pretty well (when was the
last time you couldn't get to Google because of a routing
problem on the Internet?). Hence we don't need to
calculate some exact value of "upness" (which is a good thing).
BTW, the question "is entity X up" really reduces to
Zeno's paradox (think: what is the granularity of
"upness", and how often do I need to ask?). And we know
what it took to solve Zeno's paradox. But as mentioned
above, we can do a fine job (within our engineering
constraints) with clever heuristics. The operational
Internet is pretty much an existence proof of that.
Dave
signature.asc
Description: Digital signature
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
