[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [RRG] Renumbering...



> aggregation.  For the cases that do require aggregation, it would seem
> that you have to be willing to renumber end-user sites...

That is just occurred to me: what if end users instead of ids will get just a range. E.g. here is 64 least significant bits for you to do whatever. Hence there is no need to support the name space, users can renumber as much as they want while SP could package ids with the access to those users who do not care.

Then all decisions about hierarchy and layers concentrate on prefixes that will be managed along the established RIR policies.

What do you think?


--- On Wed, 8/20/08, Tony Li <tony.li@tony.li> wrote:

> From: Tony Li <tony.li@tony.li>
> Subject: RE: [RRG] Renumbering...
> To: "'Scott Brim'" <swb@employees.org>, "'Fleischman, Eric'" <eric.fleischman@boeing.com>, rrg@psg.com
> Date: Wednesday, August 20, 2008, 1:53 PM
> 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.
> 
> Do you disagree with this?
> 
> 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


      

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