RE: [RRG] loc/id split and LISP

[Sheng Jiang <shengjiang@huawei.com>]

*>>> 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?
*
*Anyone else have an opinion?

Giving the fact that IPv6 has a large address space and that the current
core network is still mainly IPv4 based, v6-EIDs-over-v4-locators gets the
priority.

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

My consideration is the scenario that identifiers move. In this scenario,
networking topology changes too. Therefore, the topology may not be able to
guarantee the context. I am thinking it should the host that owns the
identifier to be responsible for providing the initial context information.

Sheng

*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?
*
*Dino
*--
*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