Re: [RRG] Renumbering...

[Scott Brim <swb@employees.org>]

On 8/21/08 4:34 PM, Tony Li allegedly wrote:
> Hi Scott,
>  
> |When a site network moves or merges it NEED NOT renumber -- 
> |any increase
> |in state is restricted to the first level of the mapping system and is
> |quickly damped out.  There isn't any increase in state at the sites
> |communicating with that site network either unless the network
> |fragments.  The only thing that changes is the RLOCs.
> 
> 
> Understood.  However, what happens when a site changes mapping provider?

I'm going to reply to this whole thread in one message.

To start with, what is a "mapping provider"?  There are three different
functions that seem to be getting conflated:

  a. EID prefix allocation (assuming we mean LISP)
  b. advertisement of where to find a mapping (aka mapping "indexing")
  c. providing/getting a mapping (for example the ALT)

Based on some previous discussion, I think when you say "mapping
provider" you mean (b), indexing, i.e. advertisement of where to obtain
a mapping for a prefix.  However, I am not sure, since other parts of
this thread seem to combine that with prefix allocation.

> My understanding is that the site must then change EIDs to the new
> provider's aggregate.  This would seem to create a vendor lock for the
> mapping provider.

If by "mapping provider" you mean (a) above, then that would make sense
by definition.  If you change the source of your prefix allocation, e.g.
an RIR, then you are going to get a new prefix.

If you mean (b) above, when a site changes its connectivity its prefix
remains the same, its ALT connections remain the same -- all that
changes is the mapping (since its physical connectivity and thus RLOCs
have changed).  The ALT aggregator nodes responsible for aggregating
that site's prefix, would not change.  There is no issue of connecting
to a new set of ALT aggregators unless you get a new prefix.
Speculating on what you have in mind, are you suggesting that one of the
ALT aggregators responsible for that site's prefix might refuse to
forward Map-Requests to its new RLOCs?

(c) wouldn't change.


On 8/22/08 1:14 AM, Eliot Lear allegedly wrote:On 8/22/08 3:50 AM, Eliot
Lear allegedly wrote:

> It's not so clear.  It depends on where aggregation occurs.  Also, keep
> in mind that the primary function of a mapping provider is to provide a
> stable EID prefix, so this sort of change should be extremely rare!!

"provide a stable EID prefix" ... Which definition of "mapping provider"
is this?  The original allocator of the prefix (my (a) above)?

and then Tony replies:

On 8/22/08 1:27 AM, Tony Li allegedly wrote:
> Well, unless there is some significant change, the ALT approach seemed to
> suggest that there would be a single mapping provider advertising a specific
> aggregate into the ALT topology.  Thus, I would assume that the aggregation
> would occur at the mapping provider.

... where it seems that "mapping provider" means an ALT aggregator node.

Tony: There is no reason why there should be a single ALT aggregator
node responsible for a prefix, and good reasons why there should be
more.  There would be at least two, or more, for redundancy.  A site
would connect to all, and all would advertise an aggregated prefix
including the site's prefix, further into the ALT.

On 8/22/08 3:50 AM, Eliot Lear allegedly wrote:
> There are many possible approaches to explore.  For instance, one could
> cluster providers, for instance, in a *non-geographic* fashion and
> aggregate *above* them, much the same way that OpenSRS worked in the
> early days of the domain registrars.  This would be a huge selling point
> for an alliance.

What is a "provider" here?  Are we still talking about ALT?  ALT
aggregators are "clustered" in the sense that they connect to other ALT
nodes that are responsible for longer or shorter prefixes in their
branch of the ALT tree.  Geography has nothing to do with it.  On the
other hand it is extremely likely that prefix allocation will (continue
to be) on a regional basis, as the RIRs are today, in which case the ALT
aggregators for a particular prefix could easily all be in the same region.

On 8/22/08 4:08 AM, Tony Li allegedly wrote:
>     We really don't know what sort of performance we need out of an ALT
>     provider or of the ALT as a whole.  This to me is *also* an area of
>     further research.  I think we can say with certainty that the volume
>     of BGP messages will be lower than that of what there is today, but
>     even here there is room for research.  For instance, when should
>     peering be made and when should a route simply be announced from the
>     provider without any direct contact from the subscriber?  What are
>     the performance impacts and to whom?  
>  
> I was under the impression from the presentations that I've seen that
> folks had converged.    If it's still open, then I look forward to
> further updates. 

I'm not sure what "it" is but I suspect it's when an ALT aggregator
should aggregate.  Everything is always open to reconsideration.

On 8/22/08 2:47 PM, Tony Li allegedly wrote:
> There's one significant difference, which is the initial condition.  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
> or renumber their site into their new mapping provider's EID.  

By "mapping provider" do you mean an ALT aggregator (my "(b)")?  I guess
the problem you are postulating is that a site wants to convert to LISP
but cannot find an existing ALT aggregator with an aggregation that
includes its prefix, so its prefix is advertised on the ALT
unaggregated.  More sites do the same and eventually the ALT is
overloaded.  I don't think this would happen.  The ALT is virtual, and
an ALT node that is aggregating one prefix can aggregate another one
just as well.  If the ALT accepts your prefix route at all, it will
aggregate it if possible (and not if not possible), because that lessens
its load.

I'm going to stop here and see if I understood your concepts correctly.

Scott

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