Re: [RRG] loc/id split and LISP

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2007-10-11 12:32, Dino Farinacci wrote:
> > > > Agree. The deploying cost of IPv6 is quite expensive. I started to 
> > > > work on
> > > > IPv6 and IPv6 transition since 2001. By that time, we optimistically 
> > > > think
> > > > IPv6 could replace IPv4 in 2 or 3 years giving its maturity of basic
> > > > protocols and massive advantages. Now, I have to say that we 
> > > > underestimated
> > > > the deploying cost, a lot. One more thing to be mentioned, IPv6 
> > > > provides a
> > > > lot transition approaches to support IPv4/IPv6 coexist. So far, I 
> > > > have not
> > > > seen such efforts in HIP or Node ID. (I may volunteer to do so.) And in
> > > > order to obtain the biggest benefit of HIP or Node ID, globally 
> > > > deployment
> > > > is requested. Therefore, transition solutions may not solve the 
> > > > problems.
> >
> > > One could consider doing a combination of adding a new namespace and 
> > > deploying IPv6. If the cost of deployment is too great for putting 
> > > IPv6 on hosts, then use IPv4 in hosts as the EID namespace and IPv6 
> > > deployed in the core as the locator namespace.
> > > If it is easier or more necessary to run IPv6 in the hosts, then the 
> > > opposite could occur. In fact this later case is probably more 
> > > necessary so we can have a larger address space that addresses all 
> > > the hosts in the Internet with IPv6 EIDs and use locators as IPv4 
> > > addresses with an IPv4-only core substrate.
> >
> > I took a while to think this through, but I think the answer is that
> > we should have a solution that is capable of doing *both* of these
> > scenarios.
>
> My prototype is doing v4-EIDs with v4-locators as well as v6-EIDs with 
> v6-locators.
>
> On my todo list is the "crossover". So which one should I do first, 
> v4-EIDs-over-v6-locators or v6-EIDs-over-v4-locators?

It seems that we have an ample supply of v6-EIDs and a shortage
of v4-EIDs.  So personally I'd give priority to v6-EIDs-over-v4-locators.
But SOFTWIRES is based on the other requirement...

> Anyone else have an opinion?
>
> > Further, with all these different shapes and forms of identifier
> > and locator in the picture, I think they are going to need
> > to be tagged, so that the mapping and routing systems know what
> > they are. You can't just send a 32 bit or 128 bit value and expect
> > the receiving router to know by context what it is (in terms of
> > its scope of validity). If you try to map an apple into a pear,
> > you need to know that explicitly.
>
> I think where you are in the topology defines the context (where you is 
> an ITR, TE-ITR, TE-ETR, or ETR). That is, you supply an outer header 
> based on the next-hop knowing how to route on the destination address.

You do in LISP. I'm thinking about a map distribution mechanism
that doesn't rely on that, for future-proofness. It's really
a slight generalization of the AFI, I think.

> Having said that, we can do things to avoid configuration errors. So if 
> an IPv6 address is in the TLA for EIDs, we can make sure such addresses 
> are not used as locators in config files or upon insertion into mapping 
> databases.
>
> How about the contentious issue of 240.0.0.0/4, should it be used as the 
> TLA for the EID namespace for IPv4?

Ah, yes, you have no IANA Considerations in the LISP draft...

But this does encode semantics in address bits. I know that's
been done often enough (Class E for EID has a satisfying ring),
but I'm not sure it's the right solution.

   Brian


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