RE: [RRG] Renumbering...

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: "Tony Li" <tony.li@tony.li>

    > As part of the transition plan to LISP, a new site has effectively two
    > choices: find a mapping provider that supports an EID aggregate for
    > their existing prefix

Do remember that the _provision_ of the mapping is a different issue from the
_delegation_ of the mapping - in DNS terms, the latter is having an entry in
.COM which points to company X's nameserver, and the former is company X's
nameserver providing A records (etc) for www.X_company.com. (In LISP terms,
the delegation is CDR's and the provision of the mappings is CAR's - or do I
have that back to front?)

Of course, it's the delegation step where one _has_ to rely on some other
entity, which is the point of concern a number of people have raised. (A
company could run its own mapping provider, or hire it out, as one sees now
with DNS.)

    > the new site can provide their own mapping service and not aggregate,
    > impacting the scalability of the mapping.

I don't understand this point (perhaps because I'm assuming that the mappings
will be provided by a hierarchical delegation system like CONS)?

    > The analogy of having a group of providers supporting .com is a good
    > one. If that could be worked out, that could conceivably create an open
    > market for mapping services. However, please note that such a market
    > would have to be created for each and every mapping aggregate. Unlike
    > TLDs, I suspect that we will need more top levels. How many aggregates
    > do we forsee? 1000? Frankly, I'm skeptical that we will be able to
    > create this market.

Your concern at the end of that seems to be assuming that each provider will
be servicing only one top-level aggregate. I don't see any reason the
providers wouldn't serve many/most top-level aggregates - i.e. we might have
3 providers, each of which can provide many (most?/all?) mappings.

(The exact details here are left unstated, there's something of a design
decision tree: a) if every provider does not have the entire set, then you
have to either i) ask them all in parallel, or ii) accept delays on some
lookups if you have to fail over to a secondary; or b) you mandate that all
providers carry all mappings, although some providers could be 'secondary';
i.e. they don't get the mapping directly from the client, but from one of the
other providers - i.e. they listen to each other and pick up mapping they
don't have. I don't think there are any insoluble technical problems here,
we just have to make sure we design a system which can support the business
relationships we require as well as the usual well-understood technical
ones such as security, robustness, etc.)

	Noel

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg