Re: [RRG] Renumbering...

[Scott Brim <swb@employees.org>]

On 8/20/08 1:53 PM, Tony Li allegedly wrote:
> Hi Scott,
> 
> |Excerpts from Peter Sherbin at 08:49:41 -0700 on Wed 20 Aug 2008: |>
> > translation solution.  If we go down the map-n-encap path, it |> >
> implies that we need a mapping solution that does not require |> >
> aggregation of the identifier space.  So far, there aren't a lot |> >
> of those on the table... | |I missed this the first time around.
> Tony, first you seem to be |assuming that identifiers will be in
> network layer packet headers and |that packets will be delivered
> using them (otherwise there would be no |question of needing to
> aggregate "identifiers" in network layer |routing).  Neither of these
> assumptions is required.  Identifiers are |primarily useful for
> multipath management and session continuity. |Identifiers may be in
> the network layer, and carried in network layer |packet headers, for
> convenience of the endpoints, but that doesn't |mean they should be
> included in routing information.
> 
> Given that we have no clear definition of what 'network layer' means
> in a map-n-encap architecture, I'm not quite clear on what you're
> saying.  So far, what I've seen is that map-n-encap architectures
> carry identifiers in payload headers.  This is necessary up to the
> point of encapsulation, as you have to have the data to perform the
> mapping lookup.  Again, you need to have a very scalable mapping
> solution which in some cases seems to require aggregation.  For the
> cases that do require aggregation, it would seem that you have to be
> willing to renumber end-user sites either initially or when the
> mapping provider changes.

OK, now I see.

Map-and-encap is a "jack-up".  Think of it as the Internet continuing to
run as it is, with the DFZ taken out of it and made a different layer
network.  (That is not completely the case because the name space is
still shared.)  So yes, EIDs or whatever you want to call them are
carried as "payload" across the DFZ, just as they are over Ethernet or
anything else that provides transport for the Internet.  How mappings
are discovered is orthogonal to that, but yes, in order to scale hugely
mappings should refer to aggregates.

But the EIDs, or whatever you want to call them, in a map-and-encap
scheme do not have to be the "identifiers" that (afaict) were the point
of this thread.  Map-and-encap is about routing and forwarding, not
identification.  We can have tokens (one or more) that fill all the
needs of identification without being closely associated with routing
and forwarding.


On 8/20/08 6:08 PM, Peter Sherbin allegedly wrote:
>> I think that smells remarkably like ILNP
> 
> ILNP specifically calls for 64-bits ID for a node. What I was
> suggesting is a range that can be any (64, 86, etc) based on the set
> prefix length. Also end users can put that ID anywhere they see fit:
> node, interface, port, application etc. If necessary it will be an
> architectural decision to recommend where exactly to put the ID.

Regardless of how many bits you allocate to a site, if "identifiers" are
carried in routing protocols, they also smell like "addresses", which
will be aggregated in any site with significant scale into "subnets",
and it's renumbering all over again.

As a bottom line for the renumbering question, it seems that renumbering
is desirable but is going to be painful for many sites, so it should not
be assumed to be easy, and it is a good thing to reduce the expected
need for future renumbering.  If a routing architecture requires IPv6
then it can also require one renumbering event but no more.

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