RE: [RRG] Renumbering...

["Tony Li" <tony.li@tony.li>]

Hi Noel,


|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. 


Understood completely.


|    > 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)?


Simply this: if an IPv4 site with a swamp prefix wants to participate in
ALT, what happens?  If they choose not to renumber, what happens?

Please also consider the transition plan while you're at it.  


|    > 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.


Fair, you can trivially support more than one prefix.  To continue the
analogy, this would seem to have many of the same properties as the root
nameservers in DNS.  


|(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.)


Again, I'm less concerned about the technical side of things than I am about
vendor lock vs. the cost of renumbering.  It would seem that to prevent
vendor lock, there must be a broad market of mapping providers.  And to
avoid renumbering the identifier prefix must be portable across those
mapping providers.  In short, it seems like we have to have a situation
directly analogous to what we have today with the DFZ full of swamp
prefixes.  We have a number of 'DFZ' mapping providers advertising mapping
for 0/0 and delegating the entire swamp.  Again, this feels like we haven't
solved the problem, we've just pushed it up a layer.

Regards,
Tony


--
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