Subject: [RRG] loc/id split and LISP

From: [email-masked]
Date: Mon, 1 Oct 2007 03:28:04 EDT

In my view the pair "DNS name / IPv4 address" is a true  ( identifier / 
locator ) -pair, whereas EID and RLOC are rather two  locators separated by some 
strict or loose hop.
 
Imho LISP is pure two loose hops routing. Isn't it ? LISP wouldn't make  
sense if there were no hop between EID and RLOC, would it ? (in that case, what  
would be the meaning of EID resp. RLOC ?)
 
So working out the double nature "identifier/locator" is first of all  
creating a special aura of research. 
 
Is this too critical ?
 
Heiner

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 01 Oct 2007 10:59:01 +0200

IP address within user site network is used as a component to identify a
session, which is the role of IDENTIFIER. Of course, it also plays a role of
LOCATOR in user site network. But in the transit network, the IP address
mentioned above only has a role of IDENTIFIER.

Best regards,

Xu Xiaohu

  _____  

size=2 width="100%" align=center tabindex=-1> 

发件人: [email-masked] [mailto:[email-masked]] 代表
[email-masked]
发送时间: 2007年10月1日 9:28
收件人: [email-masked]
主题: [RRG] loc/id split and LISP

In my view the pair "DNS name / IPv4 address" is a true ( identifier /
locator ) -pair, whereas EID and RLOC are rather two locators separated by
some strict or loose hop.

Imho LISP is pure two loose hops routing. Isn't it ? LISP wouldn't make
sense if there were no hop between EID and RLOC, would it ? (in that case,
what would be the meaning of EID resp. RLOC ?)

Is this too critical ?

Heiner

---

From: [email-masked]
Date: Mon, 1 Oct 2007 05:08:10 EDT

Certainly.And all the time.
Heiner

In einer eMail vom 01.10.2007 11:01:00 Westeuropäische Normalzeit schreibt  
[email-masked]:

Best  regards, 
Xu  Xiaohu 

____________________________________
size=2 width="100%" align=center tabindex=-1> 
发件人: [email-masked]  [mailto:[email-masked]] 代表  [email-masked]
发送时间: 2007年10月1日 9:28
收件人:  [email-masked]
主题: [RRG] loc/id split and  LISP

 

 
Is this too critical  ?

Heiner

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 01 Oct 2007 11:25:07 +0200

So it ‘s the EID but not DNS name that plays the role of identifier, besides, some host doesn’t have a DNS name at all.

  _____  

发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2007年10月1日 11:08
收件人: [email-masked]; [email-masked]
主题: Re: [RRG] loc/id split and LISP

Heiner

In einer eMail vom 01.10.2007 11:01:00 Westeuropäische Normalzeit schreibt [email-masked]:

IP address within user site network is used as a component to identify a session, which is the role of IDENTIFIER. Of course, it also plays a role of LOCATOR in user site network. But in the transit network, the IP address mentioned above only has a role of IDENTIFIER.

Best regards,

Xu Xiaohu

<HRsize=2 width="100%" align=center tabindex=-1> 

In my view the pair "DNS name / IPv4 address" is a true ( identifier / locator ) -pair, whereas EID and RLOC are rather two locators separated by some strict or loose hop.

Imho LISP is pure two loose hops routing. Isn't it ? LISP wouldn't make sense if there were no hop between EID and RLOC, would it ? (in that case, what would be the meaning of EID resp. RLOC ?)

So working out the double nature "identifier/locator" is first of all creating a special aura of research. 

Is this too critical ?

Heiner

</HR

---

From: [email-masked]
Date: Mon, 1 Oct 2007 06:06:54 EDT

In einer eMail vom 01.10.2007 11:26:24 Westeuropäische Normalzeit schreibt  
[email-masked]:

So it ‘s the EID but  not DNS name that plays the role of identifier, 
besides, some host doesn’t  have a DNS name at all. 

Thanks for responding, but this is not what I wanted to say. LISP may even  
have been triggered due to the identifier/locator dual nature discussion. But 
in  the end it is (imho) a two loose hops forwarding where the EID is also used 
like  a locator - well, for the second loose hop.

Heiner

---

From: Eliot Lear <[email-masked]>
Date: Mon, 01 Oct 2007 15:05:20 +0200

Hi,
> Thanks for responding, but this is not what I wanted to say. LISP may 
> even have been triggered due to the identifier/locator dual nature 
> discussion. But in the end it is (imho) a two loose hops forwarding 
> where the EID is also used like a locator - well, for the second loose 
> hop.

Everyone has a slightly different view of this, and I think yours as as 
good as any.  Dino and crew set out to tackle a very specific and well 
scoped problem, which really had very little to do with what many people 
believe is the IP/loc split.  They were out to change the nature of the 
performance curve by adding an additional tier of routing that is 
bilateral in nature rather than multilateral.  To me that's the 
fundamental challenge.  IDs and locators are not a central them in LISP, 
IMHO.  And for that matter, neither is whether you tunnel or map 
(although each has its advantages).

Eliot

--
to unsubscribe send a message to [email-masked] 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

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 08 Oct 2007 19:37:17 +0800

Catching up from the national holiday...

In my opinion, the most important point should not be whether LISP or DNS/IP
is nature identifier/locator split solution. It should be what benefit LISP
can bring us. For me, LISP partly solves the routing convergence issue with
the minimum modification on the current Internet architecture. Of course,
LISP could introduce another namespace in order to be a real
identifier/locator split solution, actually there are such approaches, but
that would be too expensive to be deployed. LISP is not the best solution,
but it is the most realistic in a short term. It is a result of compromise.

Best regards,

Dr. Sheng JIANG

IP Research Department, Networking Research Department, Network Product
Line, Huawei Technologies Co. Ltd.

*-----Original Message-----
*From: [email-masked] [mailto:[email-masked]] On Behalf Of Eliot Lear
*Sent: Monday, October 01, 2007 9:05 PM
*To: [email-masked]
*Cc: [email-masked]; [email-masked]
*Subject: Re: [RRG] loc/id split and LISP
*
*>
*Hi,
*> Thanks for responding, but this is not what I wanted to say. LISP may
*> even have been triggered due to the identifier/locator dual nature
*> discussion. But in the end it is (imho) a two loose hops forwarding
*> where the EID is also used like a locator - well, for the second loose
*> hop.
*
*Everyone has a slightly different view of this, and I think yours as as
*good as any.  Dino and crew set out to tackle a very specific and well
*scoped problem, which really had very little to do with what many people
*believe is the IP/loc split.  They were out to change the nature of the
*performance curve by adding an additional tier of routing that is
*bilateral in nature rather than multilateral.  To me that's the
*fundamental challenge.  IDs and locators are not a central them in LISP,
*IMHO.  And for that matter, neither is whether you tunnel or map
*(although each has its advantages).
*
*Eliot
*
*--
*to unsubscribe send a message to [email-masked] 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

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 8 Oct 2007 09:07:19 -0400 (EDT)

> From: Sheng Jiang <[email-masked]>

    > It should be what benefit LISP can bring us.

I agree. Nothing will succeed unless it brings an economic benefit.

    > Of course, LISP could introduce another namespace in order to be a real
    > identifier/locator split solution ... but that would be too expensive
    > to be deployed. 

Why do you feel that way? Is it because it would increase the cost of
deployment if we couldn't re-use IPv4 routers inside the LISP 'core', if we
designed a new namespace?

	Noel

---

From: [email-masked]
Date: Mon, 8 Oct 2007 09:31:09 EDT

Noel

When I mentioned all the advantages of my hierarchical model (that one  which 
was rated POOR) I forgot to mention that it does not need another  namespace.
 
Heiner

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 09 Oct 2007 09:22:11 +0800

*    > Of course, LISP could introduce another namespace in order to be a
real
*    > identifier/locator split solution ... but that would be too expensive
*    > to be deployed.
*
*Why do you feel that way? Is it because it would increase the cost of
*deployment if we couldn't re-use IPv4 routers inside the LISP 'core', if we
*designed a new namespace?
*
*	Noel

A new architecture with a new namespace could mean that we have to change
most of components of current Internet. It is a revolution rather than a
smooth transition.

For example, HIP, it requests ALL end devices change their stacks, ALL
applications to be modified in order to support HIT, and to deploy a global
mapping real-time system in order to translate the identifier (HIT) into
locator (IP). I am sure that I do not mention all the costs. Personally, I
am pessimistic the abovementioned can happen in a short future. HIP does not
improve the network routing however. HIP++, Node ID even requests more in
order to optimize network routing. It consequently requests the modification
on all the routers besides all the abovementioned requirements. Is it
expensive?

On the other side, I am not saying HIP or Node ID is a bad solution. They
are better solutions for the issues we meet now, just too expensive. Maybe,
we could afford them as a long-term revolution.

Regards,

Dr. Sheng JIANG

---

From: Tony Li <[email-masked]>
Date: Mon, 8 Oct 2007 18:38:24 -0700

> on all the routers besides all the abovementioned requirements. Is it

How is this cost any higher than that of deploying IPv6?  It seems to  
me that there's no significant qualitative cost differentiation  
between deploying v6 as it stands today and some better solution.  In  
fact, a better solution might well be easier to deploy, as the cost/ 
benefit ratio might be tolerable.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Oct 2007 15:00:37 +1300

On 2007-10-09 14:38, Tony Li wrote:
> How is this cost any higher than that of deploying IPv6?  It seems to me 
> that there's no significant qualitative cost differentiation between 
> deploying v6 as it stands today and some better solution.  In fact, a 
> better solution might well be easier to deploy, as the cost/benefit 
> ratio might be tolerable.

Tony, the work's been done for IPv6, for most infrastructure products
and a quite large chunk of applications. Good luck in asking development
managers to start over. Unfortunately this is orthogonal to the
better/worse discussion.

    Brian

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 8 Oct 2007 22:07:45 -0400 (EDT)

>>> Of course, LISP could introduce another namespace in order to be a
    >>> real identifier/locator split solution ... but that would be too
    >>> expensive to be deployed.

    > A new architecture with a new namespace could mean that we have to
    > change most of components of current Internet.

If we had to deploy it in the hosts, I agree.

However, I think it is probably possible to deploy a new namespace in
connection with LISP, if we only have to deploy it in the ITR's, ETR's, and
the routers in between them (initially, at least).

    > It is a revolution rather than a smooth transition.

I agree, a smooth, gradual transition is necessary. So I think the initial
deployment needs to be as small as possible.

For example, it might start as just a single ISP: new code gets deployed into
all their routers, but no packets are sent in that format until all their
routers are ready to handle them. Once it is verified as working and stable,
other ISP's could deploy it. Eventually some hosts might see a benefit to
implementing it. Etc, etc....

	Noel

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 09 Oct 2007 10:18:59 +0800

*> A new architecture with a new namespace could mean that we have to
*> change
*> most of components of current Internet. It is a revolution rather
*> than a
*> smooth transition.
*>
*> For example, HIP, it requests ALL end devices change their stacks, ALL
*> applications to be modified in order to support HIT, and to deploy
*> a global
*> mapping real-time system in order to translate the identifier (HIT)
*> into
*> locator (IP). I am sure that I do not mention all the costs.
*> Personally, I
*> am pessimistic the abovementioned can happen in a short future. HIP
*> does not
*> improve the network routing however. HIP++, Node ID even requests
*> more in
*> order to optimize network routing. It consequently requests the
*> modification
*> on all the routers besides all the abovementioned requirements. Is it
*> expensive?
*
*
*How is this cost any higher than that of deploying IPv6?  It seems to
*me that there's no significant qualitative cost differentiation
*between deploying v6 as it stands today and some better solution.  In
*fact, a better solution might well be easier to deploy, as the cost/
*benefit ratio might be tolerable.
*
*Tony

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.

Best regards,

Dr. Sheng JIANG

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Oct 2007 21:24:34 -0700

> is requested. Therefore, transition solutions may not solve the  

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.

Dino

---

From: Tony Li <[email-masked]>
Date: Mon, 8 Oct 2007 21:35:18 -0700

> managers to start over. Unfortunately this is orthogonal to the

Brian,

I think you greatly overestimate the amount of work that's been done as
compared with the amount of work left to be done.  There would still  
seem
to be a lot of maturity lacking in v6 products.  I recently saw an  
ICANN survey
that showed about 30% of firewall products support v6.

Besides, many of the proposals might not require starting over from  
scratch.

Finally, development manager will do what the market requires.  If  
something
else will end up with more revenue than v6, it will get implemented more
quickly than v6.

The key to the whole equation is finding the appropriate forcing  
functions to get people
to deploy.  Motivation is everything.

Tony

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 10 Oct 2007 14:08:46 +0800

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

It is a good suggestion, Dino. However, it may be a little bit late. The
deployment IPv6 has been ongoing for years. It might be easier if we tried
to combine these two when IPv6 was initially designed. On the other hand,
the doubt on IPv6 is becoming more and more while the deployment and
transition takes much longer than originally expected, and seems still need
a quite long time.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Oct 2007 10:06:11 +1300

On 2007-10-09 17:24, Dino Farinacci wrote:
> 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.
> 
> 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.

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.

    Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Oct 2007 16:32:31 -0700

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

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?

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Oct 2007 12:52:03 +1300

On 2007-10-11 12:32, Dino Farinacci wrote:
> My prototype is doing v4-EIDs with v4-locators as well as v6-EIDs with 
> v6-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...

> 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

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 10 Oct 2007 21:12:21 -0400 (EDT)

> From: Dino Farinacci <[email-masked]>

    > Anyone else have an opinion?

I think other stuff (e.g. mapping distribution) is probably more important,
actually...

    > the TLA for the EID namespace for IPv4?

I think it actually makes more sense to use that space for LISP RLOC's. My
reasoning is that there are some issues with the use of that space in some
hosts, whereas if we use it for RLOC's, we only have to make sure that the
ITR's, ETR's, and intervening routers handle it properly.

Also, a namespace of a given size which is used for EIDs can be used more
efficiently than when it is used for locators. So we'll be able to squeeze
more names out of the rest of the IPv4 namespace once it it used for EIDs;
we don't have to rely on using up the 240/4 space to get more of them.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 10 Oct 2007 21:27:13 -0400 (EDT)

> From: Brian E Carpenter <[email-masked]>

    > 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
    > 32 bit or 128 bit value and expect the receiving router to know by
    > context what it is 

Well, in general I agree (and that's one of the reasons I'm not wild on
re-using existing namespaces). But in practise it may not always be possible;
e.g. when they are used in existing protocols/software, you're kind of stuck.

	Noel

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 11 Oct 2007 09:33:54 +0800

*>>> 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 [email-masked] 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Oct 2007 14:39:51 +1300

> e.g. when they are used in existing protocols/software, you're kind of stuck.

Indeed. However, a new entity (such as LISP, or some smart kind of NAT)
could understand the tag, and ensure that it passed on an "address"
appropriate to the existing protocols/software.

     Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Oct 2007 23:20:32 -0700

> I think other stuff (e.g. mapping distribution) is probably more  

I would have to agree with you.

>> nHow about the contentious issue of 240.0.0.0/4, should it be used as

Then all ISPs have to renumber if we do that. And they would have to  
ask/force their customers to renumber their ETRs.

If locators are the addresses used in the BGP core today, less things  
have to change. And we don't have to require 240.0.0.0/4 to be used  
for EIDs. So host address changes can happen over time. The current  
PI allocations to site hosts can still be used.

Things won't be as clean as we would like but that is the cost of  
incremental/least-cost changes to get a Loc/ID split deployed. You  
have made this comment many times before.

> more names out of the rest of the IPv4 namespace once it it used  

Very true. So 240.0.0.0/4 won't get fragmented like we have today  
with ISP and RIR allocations. Therefore I think its better to have  
240.0.0.0/4 used for an EID namespace.

> we don't have to rely on using up the 240/4 space to get more of them.

True.

Dino

---

From: "Simon Schuetz" <[email-masked]>
Date: Thu, 11 Oct 2007 11:08:01 +0200

> on all the routers besides all the abovementioned requirements. Is it

This is not completely true. Node ID does not require to modify ALL routers. 
What it requires is a modification to the routers at locator domain (LD) borders.
The routers inside an LD (that do not route to other LDs) remain pure IP routers.

>From that perspective it's similar to changing all ETRs and ITRs I would say.

Simon

---

From: Mark Townsley <[email-masked]>
Date: Thu, 11 Oct 2007 11:40:39 +0200

> But SOFTWIRES is based on the other requirement...
It has both as requirements. v6/v4 and v4/v6

- Mark

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 11 Oct 2007 08:30:56 -0400 (EDT)

>> I think it actually makes more sense to use that space for LISP RLOC's.

    > ask/force their customers to renumber their ETRs.

Actually, I wasn't suggesting that all RLOC's have to come from that space
(which certainly has the disadvantages that you list), merely that if it is
released, that it be used for RLOC's. 

I do not think we can require either namespace (EID's or RLOC's) to be
entirely allocated from 240/4; that would have the same problem for either
use, i.e. it would require a lot of renumbering.

Plus to which the IETF as a whole might not agree to allocate that space to
LISP, and one of the great charms of LISP is that it can start (and be
useful) with a very small initial deployment, without getting universal
buy-in.

    > incremental/least-cost changes to get a Loc/ID split deployed. 

Exactly.

    > I think its better to have 240.0.0.0/4 used for an EID namespace.

The problem with that is that if a host is given a 240/4 address as an EID,
for it to successfully operate, not only does *it* have to operate correctly
with 240/4 addresses, but so do *all the other hosts* with which it might
want to inter-operate. So, legacy hosts are going to make use of 240/0 for
EID's (or for host addresses in general) problematic.

Far better to use it in a more limited context, i.e. the LISP backbone.

And, like I said, once the rest of the namespace space becomes EIDs, we'll be
able to use the legacy space more densely, giving us extended life in that
part of the space.

	Noel

---

From: [email-masked]
Date: Thu, 11 Oct 2007 14:49:34 EDT

In einer eMail vom 11.10.2007 14:32:32 Westeuropäische Normalzeit schreibt  
[email-masked]:

Exactly.

imho it is the wrong method to pursue that solution which needs the  least 
incremental changes.
In the end, the costs may be more than the gains. 
Two centuries ago mathematicians invented the logarithm by which they could  
reduce the complexity of multiplications/divisions to that of  
additions/substractions. It paid off, especially as there were no  computers. I believe the 
real topic is the elimination of the scalability  problem rather than the 
deployment of the Loc/ID split.
 
Heiner

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 11 Oct 2007 23:05:33 -0700

> released, that it be used for RLOC's.

Okay, makes more sense.

> use, i.e. it would require a lot of renumbering.

Definitely agree.

> EID's (or for host addresses in general) problematic.

This is true, the "it's hard to upgrade hosts" issue.

> able to use the legacy space more densely, giving us extended life  

Right.

Dino

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Oct 2007 17:46:01 +0200

> Then all ISPs have to renumber if we do that. And they would have  
> to ask/force their customers to renumber their ETRs.

This is important:

If we can't easily renumber ETRs then the entire effort is a waste of  
time, because we'll have to jack up again one or two decades from now.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Oct 2007 17:38:48 +0200

> compared with the amount of work left to be done.  There would  
> still seem
> to be a lot of maturity lacking in v6 products.

That sounds like a half full / half empty kind of discussion. All  
major OSes support IPv6. For nearly all of the top 10 applications  
used over the internet there are IPv6 capable servers and clients.  
There are routers that can forward IPv6 at the highest available line  
rates.

> I recently saw an ICANN survey

Ah yes, firewalls. It wouldn't surprise me if only 30% of them  
supports the TCP window scale option even though that has been in  
wide use for more than a decade.

> to deploy.  Motivation is everything.

If people are happy with IPv4, what's wrong with that? The IETF  
created IPv6, it's now available to anyone who wants it. That should  
be enough.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 12 Oct 2007 09:57:57 -0700

> If we can't easily renumber ETRs then the entire effort is a waste  
> of time, because we'll have to jack up again one or two decades  
> from now.

That is easy to do. That's not the problem. The problem is to try to  
put less items on the todo list.

Dino