Subject: [RRG] What does incremental deployment mean

From: Xu Xiaohu <[email-masked]>
Date: Mon, 17 Mar 2008 14:58:37 +0100

> 
> It is not obvious to me that changing operating systems
> (and/or applications) necessarily prohibits incremental
> deployment.  draft-rja-ilnp-intro-00.txt provides a specific
> example of a host stack change architecture that I believe
> to be incrementally deployable.  At least some major host OS
> vendor folks agree with that assessment.

I definitely agree to your opinion. We should not judge whether an approach
supports incremental deployment just by whether host change is required.
Nowadays, host upgrade is not such a hard work. Moreover, the id/locator
split is not a so urgent demand that required to be deployed within the
coming 3-5 year.

Since there is some possibility and benefit of introducing host change in
solving the routing scalability issue, how about involving some people from
host OS vendor to join this discussion?

Best wishes,
Xiaohu XU

--
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]
Date: Mon, 17 Mar 2008 13:38:50 EDT

I think we should hereby distinguish between data plane and routing plane  
and ask
what does incremental deployment mean in either case.
 
Associated is the question how backward compatibility  is enabled, again in 
either case.
 
All of this needs an answer, and yes, also a good solution, but at the  right 
time.
It should not be the number one issue at the beginning. At first comes the  
architectural design, then come the details which include "what needs to be  
transmitted when and how". 
 
Wrt data plane:
According to the resulting model, the details of a new IPvN header have to  
be specified (whatever that will be). We should not go after an architecture  
which assumes that IPv4 resp. IPv6 as defined in the last millenium are the 
best  ever and must therefore be kept unchanged.
Obviously a new IPvN header will be identified by a new protocol type. What  
ever its other details will be, for reasons of backward compatability, a "new" 
 router must be able to convert it back to some IPv4 header, if the 
forwarding-to  neighbor is not as knowledgeable - at least for a certain subset of  
destinations.
 
Wrt. routing plane:
A new routing model could be installed completely apart from the existing  
ones (BGP,OSPF).
It wouldn't happen for the first time: Sailors know to use the stars, the  
sun, the compass , the GPS for orientation. Not always all possibilities  are 
available.
 
I am pretty sure, that after the model has been determined, acceptable  
enhancement as well as acceptable compromises will be found for solving the  
backward compatibility issue.
 
Heiner

---

From: "Tony Li" <[email-masked]>
Date: Mon, 17 Mar 2008 10:55:30 -0700

|Since there is some possibility and benefit of introducing 
|host change in
|solving the routing scalability issue, how about involving 
|some people from
|host OS vendor to join this discussion?

FWIW, some host folks have been invited.  If you know of other folks who
would be beneficial, please feel free to spread the word.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Tue, 18 Mar 2008 12:37:16 +1100 (EST)

Short version:   The two differing understandings of "incrementally
                 deployable" may result from asking two different
                 questions.

Hi Xiaohu,

You wrote:

> I definitely agree to your opinion. We should not judge whether an 
> approach supports incremental deployment just by whether host change 
> is required.

Yes, the examples I gave in: 

  http://psg.com/lists/rrg/2008/msg00826.html

include one which is a host upgrade, which I consider "incrementally
deployable".

> Nowadays, host upgrade is not such a hard work. 

This may be true, over a few years, for some hosts - perhaps even many
desktop and server machines.  If there are direct benefits for the
host's user of doing so, without relying on the host at the other end of
the communication to be upgraded too, then I would say it is
"incrementally deployable".

Here are the two questions which I think give rise to the different
understandings:

I think Tony asks something like:

  Can the technology be introduced one host at a time, one
  network at at time etc. without disrupting other networks
  - and produce some benefits?

Clearly, a technology which needs to be introduced everywhere before it
produces any benefits is not incrementally deployable.

However, the answer to this question is probably "yes" for almost any
technology.

The question I ask, and which I thought everyone else asks, is:

  Does the technology produce substantial benefits for whoever 
  installs it without relying on how many other people install it?

My examples in the above-linked message illustrate this distinction.

  - Robin

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 22 Mar 2008 23:45:55 -0500

Thus spake "Xu Xiaohu" <[email-masked]>
> approach supports incremental deployment just by whether host
> change is required.

That shouldn't be the only criterion, no, but IMHO it's one of them.

> Nowadays, host upgrade is not such a hard work.

It's not much work per host, no.  However, it's a massive amount of work 
when you multiply that by the number of hosts out there.  It's an even more 
massive amount of work to convince the owners of those machines they _need_ 
an upgrade enough to justify the money and effort.  I know plenty of people 
still running Win95, Win98, and Win2k, and most are on WinXP, not Vista.

If you're relying on people deploying the latest OS, expect at least 5 years 
to reach 50% penetration -- after the 10 years it takes to get your solution 
into the OS in the first place.  This, to me, stretches the definition of 
"incrementally deployable" or "not such hard work".

> host OS vendor to join this discussion?

My views on this point would change significantly if Microsoft in particular 
were to commit to including a host-based solution in the next version _and_ 
back-porting it to prior versions via Windows Update.  Without that 
commitment, I view any solution that _requires_ host changes to be 
infeasible.  I would not object to a solution that had _optional_ host 
changes that improved performance, though.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 25 Mar 2008 11:34:05 -0400 (EDT)

> From: "Stephen Sprunk" <[email-masked]>

    > if Microsoft in particular were to commit to including a host-based
    > solution in the next version _and_ back-porting it to prior versions
    > via Windows Update. Without that commitment, I view any solution that
    > _requires_ host changes to be infeasible.

You can drop the "Without that commitment". It's very simple:

  Any solution that *requires* host changes is infeasible.

End of story.

(For one, earler versions of Windows don't use/support Windows Update, and a
lot of people have it turned off anyway, from paranoia/prudence/whatever. But
just in general, there's a lot of old stuff out there, not just Windows.)

    > I would not object to a solution that had _optional_ host changes that
    > improved performance, though.

This is the obvious strategy. The support for unmodified hosts has to work
(and note, "work" != "work well"), but for most new capabilities, it's
reasonable to say that you have to update your stuff to gain access to those
new capabilities.

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Mar 2008 08:41:16 -0700

> just in general, there's a lot of old stuff out there, not just  

Even if everyone had Windows Update enabled, it would take too long to  
get every system upgraded.

The most popular network-based application is your favorite browser.  
How many of them are not on the latest rev?

Upgrading roughly 2 to 4 CE routers at every site on the Internet will  
happen in far less time than changing every host.

Dino

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 25 Mar 2008 18:04:36 +0100

Hi Noel and Dino,

> >  Any solution that *requires* host changes is infeasible.

According to this criteria, many proposals, including v6 EID over v4 RLOC of
LISP have been sentenced to death.

> get every system upgraded.

Most of today's core routers have already been able to support more than 1
million routing entries, is there enough incentive for the carriers to
deploy map&encap scheme within a short period. 

Should we take a survey to reach an agreement on when the new address and
routing scheme should be deployed?

> happen in far less time than changing every host.

The approach that map implemented by hosts and encapsulation implemented by
ITRs is incremental deployable. If hosts have not been changed to support
this capability, the ITR can implement the map and encapsulation together.
The upgraded hosts will not suffer the initial packet loss/latency pain. And
the ITR with upgraded site network doesn't need a cache.

Best wishes,
Xiaohu XU

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Mar 2008 10:13:23 -0700

> LISP have been sentenced to death.

No, not true. We assume and it is a safe assumption that hosts already  
have IPv6 stacks. And IPv6 EIDs with IPv4 RLOCs means your LISP router  
has to do it.

That is life if I have ever seen it.

> deploy map&encap scheme within a short period.

Carriers don't deploy it. Sites do because they want easier ways to do  
multihoming.

> routing scheme should be deployed?

Loc/ID split helps solve the routing table size problem. But that is  
just 1 feature of it.

> the ITR with upgraded site network doesn't need a cache.

What is the point of having them both do it?

Dino

---

From: "William Herrin" <[email-masked]>
Date: Tue, 25 Mar 2008 13:34:50 -0400

On Tue, Mar 25, 2008 at 11:34 AM, Noel Chiappa <[email-masked]> wrote:
>   Any solution that *requires* host changes is infeasible. End of story.

Noel,

I'm not comfortable with quite that broad a statement. Consider the
following scenario:

You create a map-encap system. There are some host software upgrades
that make everything work great. Non-upgraded hosts still work, but
they suffer a 10% performance penalty and certain diagnostic tools
(like traceroute) malfunction.

Do we want to eliminate this scenario from consideration before we've
seen what capabilities and efficiencies it enables?

I'd go for a slightly more moderate statement: A solution is
infeasible if host changes are a -prerequisite-.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 25 Mar 2008 18:42:04 +0100

Hi Dino,

> have IPv6 stacks. And IPv6 EIDs with IPv4 RLOCs means your LISP router

As Noel said, "there's a lot of old stuff out there, not just Windows."
Does that statement mean there are still a small part of hosts without IPv6
capability? 

If your assumption is correct, then what's the main obstacle for the
transition from v4 to v6 since IPv6 is already enabled on most hosts? 

> Carriers don't deploy it. Sites do because they want easier ways to do

Provided the above was the main drive for the map&encap scheme, though the
site with multiple ETRs can enjoy the multihoming benefits, what's the
incentive for the other site to deploy the ITR?

...

> What is the point of having them both do it?

This is a transition strategy just like the dual stacks. Of course, if there
was a solution which can overcome the side-effects of the cache mechanism
and the long stretch forwarding path, it's not necessary to upgrade the
hosts to support this mapping querying function.

Best wishes,
Xiaohu XU

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Mar 2008 10:54:34 -0700

> transition from v4 to v6 since IPv6 is already enabled on most hosts?

What I meant was that you wouldn't any more changes to IPv6 stacks to  
support LISP at the site.

Noel's point stands strong and it would be nice for those systems that  
will never get upgraded that they can still use the Internet.  ;-)   
Err, nice.... I mean necessary.

> incentive for the other site to deploy the ITR?

For the same incentive. Any site who wants to receive packets on  
multiple ISP links would have incentive.

I think we can all agree and a safe assumption that every site in the  
world would want bidirectional connectivity?  ;-)

> hosts to support this mapping querying function.

You think the Internet can take more than one transition? I haven't  
seen any yet in 25 years. And NCP to TCP happened because a few  
researchers just pushed it through.

I bet the number of people using NCP were less than the number of  
people on this mailing list.  ;-)

Dino

---

From: Randall Atkinson <[email-masked]>
Date: Tue, 25 Mar 2008 11:44:57 -0700

Earlier, Dino wrote:
% Even if everyone had Windows Update enabled, it would take too long to
% get every system upgraded.

I am told the majority of Windows systems are updated each month,
and that within 3 months the overwhelming majority of Windows systems
have been updated.

Three months clearly is not "too long", and that seems to be the time
frame -- according to folks I've talked with at Microsoft.  Perhaps someone
at Microsoft can provide specific numbers to clarify.

% The most popular network-based application is your favorite browser.
% How many of them are not on the latest rev?

Upgrading a stack and upgrading a particular application are not similar.
For security reasons, most Windows users do have Windows Update
enabled these days.  That might not have been true 8-10 years ago,
I don't know, but it is reportedly true today.

Similarly, MacOS X users overwhelmingly apply patches/upgrades within
a week or so of their becoming available.

% Upgrading roughly 2 to 4 CE routers at every site on the Internet will
% happen in far less time than changing every host.

I know of a number of sites still with AGS+ and even CGS boxes deployed,
so it is not at all clear that claim is true.

However, regardless of what one thinks, this thread isn't going to converge
this RG membership anytime soon on this topic.  Probably best for everyone
to move along...

Ran

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Mar 2008 14:15:47 -0700

> so it is not at all clear that claim is true.

So if you are using my argument about routers, then it is even more so  
with hosts.

Dino

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 25 Mar 2008 19:56:01 -0400 (EDT)

> From: Xu Xiaohu <[email-masked]>

    > The approach that map implemented by hosts and encapsulation
    > implemented by ITRs is incremental deployable. If hosts have not been
    > changed to support this capability, the ITR can implement the map and
    > encapsulation together. The upgraded hosts will not suffer the initial
    > packet loss/latency pain.

This does sound like an example of the approach I gave earlier; unmodified
hosts 'work', although they do not work 'well'.

    > From: "William Herrin" <[email-masked]>

    > ... Non-upgraded hosts still work, but they suffer a 10% performance
    > penalty and certain diagnostic tools (like traceroute) malfunction.
    > ...
    > I'd go for a slightly more moderate statement: A solution is infeasible
    > if host changes are a -prerequisite-.

Umm, I thought that was just what I said (as the following comment from my
orignal post says):

    >> The support for unmodified hosts has to work (and note, "work" !=
    >> "work well")

I'm perfectly happy with "prerequisite" instead of "required" - to me, they
meant exactly the same thing.

	Noel

---

From: [email-masked]
Date: Wed, 26 Mar 2008 05:04:18 EDT

In einer eMail vom 25.03.2008 16:34:55 Westeuropäische Normalzeit schreibt  
[email-masked]:

End of  story.

Ha, so we need to have a proxy-host.
pity, PTR, pitiest...
 
Three more jokes:
 
- Let's disregard the address depletion issue and the growth of tables and  
update churn will stop all by itself.
 
- Today the fairly routable E.164 numbers (which includes country code,  area 
code) are mapped to the, wrt. routing, really not meaningfull IP  addresses  
 
- Siemens tries to sell its switch-department SEN, complaing that it  has 
missed to convert switches to routers. Imagine if all switches  would be 
L3-routers such that "dial-in" connections aren't needed ! The internet  would have 
hit the wall already a while ago
 
Heiner

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 26 Mar 2008 10:06:00 +0100

> hosts 'work', although they do not work 'well'.

Hi Noel,

Exactly. Map implemented by hosts is an optimization but not a prerequisite.

Best wishes,
Xiaohu XU

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 27 Mar 2008 18:18:49 -0400

> and that within 3 months the overwhelming majority of Windows systems

Define "overwhelming majority".

Rather than just pontificate, I will try and provide some possibly  
useful data.
Here is a summary of last week's access
from one of my web servers (various sites including parts of  
AmericaFree.TV; statistics
based on the Apache web server logs) :

  OS Build = Windows NT 5.1                           | Hits =  
414124  or  62.84 %
  OS Build = Windows NT 6.0                           | Hits =  
101704  or  15.43 %
  OS Build = unknown                                  | Hits =   
54129  or   8.21 %
  OS Build = Intel Mac OS X                           | Hits =   
22148  or   3.36 %
  OS Build = Windows NT 5.0                           | Hits =   
21654  or   3.29 %
  OS Build = Linux i686                               | Hits =   
18308  or   2.78 %
  OS Build = PPC Mac OS X Mach-O                      | Hits =    
7077  or   1.07 %
  OS Build = PPC Mac OS X                             | Hits =    
5861  or   0.89 %
  OS Build = AOLBuild 4334.34                         | Hits =    
2205  or   0.33 %
  OS Build = Windows 98                               | Hits =    
1904  or   0.29 %

To translate to marketing speak

Windows NT 5.0 = Windows 2000
Windows NT 5.1 = Windows XP
Windows NT 6.0 = Windows Vista

There is a lot of this material available, in my experience the  
relative proportions change pretty slowly with time and are pretty  
consistent across sites.

Distributing "unknown" among the OS types proportional to their  
announced use, I somehow doubt that the
4.4 % of Windows users using Windows 98 and Windows 2000 update at  
all, and I wonder
about the majority of the users using using Windows XP. (I would also  
wonder if Microsoft would commit to upgrading an old OS, XP, with  
some new routing stuff in the kernel.)

So, I would conclude that for sure ~4 % of Windows users don't update  
often, and it is possible a majority doesn't.
I'm with Dino here.

Regards
Marshall

---

From: Randall Atkinson <[email-masked]>
Date: Fri, 28 Mar 2008 06:04:36 -0700

Marshall,

  I meant "update" in the sense of "apply the periodic patches
released from Microsoft", not in the sense of "buy a new copy of Windows".

Cheers,

Ran

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 28 Mar 2008 10:04:02 -0400

> released from Microsoft", not in the sense of "buy a new copy of  

I understand that, and tried to distinguish between the two in my  
little analysis.

By the way, Wikipedia says about Windows 2000

"More than eight years after its release, it continues to receive  
patches for security vulnerabilities on a near-monthly basis."

So, there may be hope there after all. Still, my experience is that  
people who are running old versions of code are
likely to also not be regularly updating them.

Regards
Marshall

---

From: Pekka Savola <[email-masked]>
Date: Sat, 29 Mar 2008 09:40:08 +0200 (EET)

On Fri, 28 Mar 2008, Marshall Eubanks wrote:
> "More than eight years after its release, it continues to receive patches for 
> security vulnerabilities on a near-monthly basis."
>
> So, there may be hope there after all. Still, my experience is that people 
> who are running old versions of code are

Isn't this whole discussion irrelevant?

Even if all Windows 2000 or XP users were applying security patches 
(which they aren't), making a fundamental change as this cannot be 
deployed as a security fix.  By definition it is going to break a lot 
of applications or at least change their communication patterns in 
such a way that in the deployed base of O(million) various kinds of 
bizarre apps and O(100 million) hosts the result would be a chaos.

There is no way any vendor could unilaterally deploy significant host 
changes in a channel meant only for critical software updates for a 
product well beyond its end-of-life cycle.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Tony Li" <[email-masked]>
Date: Sat, 29 Mar 2008 08:57:04 -0700

|Even if all Windows 2000 or XP users were applying security patches 
|(which they aren't), making a fundamental change as this cannot be 
|deployed as a security fix.  By definition it is going to break a lot 
|of applications or at least change their communication patterns in 
|such a way that in the deployed base of O(million) various kinds of 
|bizarre apps and O(100 million) hosts the result would be a chaos.
|
|There is no way any vendor could unilaterally deploy significant host 
|changes in a channel meant only for critical software updates for a 
|product well beyond its end-of-life cycle.

Deploying host changes is tractable if it doesn't have a significant impact
on the applications.  If the semantics of the API aren't violated, then
there's no significant issue.  For example, one could provide a new
transport layer (ala Mark's proposal) in parallel with existing TCP and
there would be no disruption.

One could deploy GSE-style solutions for v6 and that would only affect v6
applications that embedded v6 addresses.  Also a reasonable approach.

Tony

---

From: David R Oran <[email-masked]>
Date: Mon, 31 Mar 2008 15:35:42 -0400

Hmmm, lets see what I have, just in my little old house:

Windows: 	1 XP box, updates weekly, no IPv6
MACOSX:		3 Macs, updates weekly, dual stack
Linux:		1 Ubuntu Server, updates weekly, dual stack
Apple Airport	2 (G+N), IPV6, Updates ~monthly
NAS		1 ReadyNAS with some embedded OS (probably Linux), updates  
yearly, no IPv6
IP phone	1 Cisco 7960, updates essentially never, no IPv6
Cisco router	1 871 VPN router, no IPv6 on image I run, updates about  
every 6 months
Cisco switch	1 CAT3650 router/switch, no IPv6 on image I run, updates  
yearly
Linksys WRT	1 Home router, no IPv6, updates never
Tivos		3 no IPv6, some embedded OS, updates ~ each 6 months
Squeezebox	1 no IPv6, updates never
MoCA ECBS	3 NO IPV6, Updates ???
HP printers	2 no IPv6, updates never

So I can imagine it being reasonable to handle host changes on about  
half of these. At best. And certainly not with a flag day just inside  
my little orandom.net domain.

DaveO.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Mar 2008 14:21:16 -0700

> hmmm, lets see what I have, just in my little old house:
>
> Cisco switch	1 CAT3650 router/switch, no IPv6 on image I run,  
> updates yearly
> half of these. At best. And certainly not with a flag day just  
> inside my little orandom.net domain.

Kinda of reminds me of dual-stack.

So with a edge-box solution you can convert the entire site at one- 
time, so you could never have a dual LISP *and* non-LISP site. I think  
a huge feature.

Dino

---

From: Randall Atkinson <[email-masked]>
Date: Mon, 31 Mar 2008 14:53:03 -0700

Earlier, Dave Oran wrote:
% So I can imagine it being reasonable to handle host changes on about
% half of these. At best. And certainly not with a flag day just inside
% my little orandom.net domain.

>From your summary, it sounds like any router changes are also very far
from being a given.

Ran

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 01 Apr 2008 12:13:15 +0200

> From your summary, it sounds like any router changes are also very far

It seems that using multiple independent IPv4 address spaces in an
id/locator split solution to address the IPv4 address depletion issue is
reasonable.

Best wishes,
Xiaohu XU

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 1 Apr 2008 06:58:02 -0700

>-----Original Message-----
>From: Xu Xiaohu [mailto:[email-masked]] 
>Sent: Tuesday, March 25, 2008 10:05 AM
>To: 'Dino Farinacci'; 'Noel Chiappa'
>Cc: [email-masked]
>Subject: re: [RRG] What does incremental deployment mean
>
>Hi Noel and Dino,
>
>> 

I don't think this is true at all; at least it better not
be. AFAICT, IPv6 as EID and IPv4 as RLOC is our best path
toward an IPv6 Internet.

Fred
[email-masked]

>implemented by

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 01 Apr 2008 16:26:33 +0200

> be. AFAICT, IPv6 as EID and IPv4 as RLOC is our best path

In the above approach, IPv6 should also play the role of locator in site
networks which implies that the site network should support IPv6. 

Have most of the site networks been ready for IPv6?  Is it easy to upgrade
the routers in all the site networks to support IPv6? If the answers to the
above questions are "No", How about using IPv4(globally unique)+IPv4(locally
unique) or LD ID/AS num + IPv4(locally unique) as locator whereas using IPv6
just as identifier?

Best wishes,
Xiaohu XU

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 1 Apr 2008 07:29:46 -0700

>Sent: Tuesday, April 01, 2008 7:27 AM
>To: Templin, Fred L; 'Dino Farinacci'; 'Noel Chiappa'
>Cc: [email-masked]

There is already a name for this; it is called ISATAP:

  http://www.ietf.org/rfc/rfc5214.txt

Fred

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 01 Apr 2008 17:20:28 +0200

>   http://www.ietf.org/rfc/rfc5214.txt
Hi Fred,

ISATAP is indeed an interesting point. However, there is still some work to
do for ISATAP to act as a scalable Internet routing architecture. Suppose
that the whole Internet is composed of many independent IPv4 address spaces,
which are connected via ISATAP routers. The ISATAP router still needs to
route packets based on the EID (IPv6), which is not scalable since the EID
should be topology-irrelevant. Besides, in a multi-homed IPv4-enabled site
network, the dual-stack host will obtain multiple IPv6 addresses from
different ISATAP gateways, which one should be used as EID?

Best wishes,
Xiaohu XU

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 1 Apr 2008 09:02:56 -0700

>do for ISATAP to act as a scalable Internet routing architecture.

ISATAP was designed as an *intra-site* map-and-encaps
architecture, where the traditional view of "site" deals
with connected network regions that occur at the edges,
e.g., a home network, a corporate enterprise network,
a MANET, etc. But, the interdomain routing core can also
be considered a "site" of sorts, so it is possible the
domain of application should be widened. 

>Suppose
>which are connected via ISATAP routers.

Let's think of the Internet as a gigantic inner site
that connects outer edge sites that have ISATAP routers
at their borders. The ISATAP routers have global IPv4
addresses assigned on their Internet-facing interfaces,
private IPv4 addresses assigned on their site-internal
IPv4 interfaces, and link-local IPv6 addresses assigned
on their site-internal ISATAP interfaces (which are
virtual interfaces configured over the site-internal
IPv4 interfaces).

When an ISATAP router for edge site A needs to forward
an IPv6 packet to node X in edge site B, some Internet
wide map-and-encaps scheme (e.g., LISP) will determine
the global IPv4 locator for the ISATAP router at site B.
When the ISATAP router at site B receives the packet,
it will in turn do an edge site-internal map-and-encaps
to determine the private IPv4 locator for a dual-stack
router within the site that serves node X. So, there are
(at least) two levels of map-and-encaps and two levels of
IPv4 locators; the first within the Internet core and the
second at the edge site-interal level.

>The ISATAP router still needs to
>should be topology-irrelevant.

As described above, it is (at least) two levels of IPv4
map-and-encaps, followed by a single level of IPv6 routing
within the edge site. The IPv6 address is only an EID up
until the ultimate edge of the edge site, where it may also
serve as an RLOC within a limited IPv6 edge routing domain.

>Besides, in a multi-homed IPv4-enabled site

Obtaining IPv6 addresses for assignment on ISATAP interfaces
through SLAAC is one alternative, but obtaining IPv6 prefixes
for assignment on other site-internal interfaces (including
loopback interfaces) may be the preferred method. (Note that
/128s can be obtained through prefix delegation the same as
for any IPv6 prefix.) But that said, I agree there is a gateway
aggregation consideration for the ISATAP gateways of multi-homed
sites.

Failing a gateway aggregation mechanism, the dual-stack end-system
(host or router) should use the ISATAP router that delegated its
IPv6 prefixes as its egress gateway to the Internet (e.g., due to
uRPF checking). The gateway aggregation solution space is being
addressed in the IETF AUTOCONF working group.

Thanks - Fred

PS Although the above is couched solely in terms of map-and-encaps,
   ISATAP still works within the edge sites whether the Internet
   core is using map-and-encaps or some form of global IPv6 routing.

---

From: Robin Whittle <[email-masked]>
Date: Wed, 02 Apr 2008 05:21:49 +1100

Hi Fred,

You wrote:

>> According to this criteria, many proposals, including v6 EID over v4
>> RLOC of LISP have been sentenced to death.
> 

I think it is true, since v6 EIDs mean that all participating hosts
must be using IPv6 addresses for all their applications.

This can't happen for a large number of hosts, or a nearly complete
coverage of hosts, without major host changes to their OS and/or
their applications.

Also, these hosts would need IPv6 connectivity in some way, at least
to and from the ITRs and ETRs they rely upon - so that would involve
router changes, more ISP management work etc.  If the IPv6
connectivity only went as far as the nearest ETRs and ITRs, how
would hosts send and receive packets to and from IPv6 hosts which
were not part of the map-encap scheme?

>From what I understand from your description of ISATAP:

  http://psg.com/lists/rrg/2008/msg01086.html
  http://www.ietf.org/rfc/rfc5214.txt

all participating hosts must be using IPv6 for all their applications.

That means ISATAP would not come close to meeting the criteria of
deployability I described in (10) here:

  Re: [RRG] What does incremental deployment mean - 2 questions
  2008-03-22 http://psg.com/lists/rrg/2008/msg00957.html

This criteria has no short name, but here are two shortish
descriptions, followed by a fuller definition:

     "No significant barriers to widespread deployment due to
      initially low uptake rate, or disruption of existing
      practices"

or:  "The zero (or relatively low) critical mass criteria for
      ubiquitous deployment on an incremental basis without
      outside inducements"

  (10) The technology must be able to be introduced without
       disrupting existing practices.  After some low
       specified level of initial deployment, ideally zero,
       everyone (or at least most people) who deploys the
       technology receives benefits (maybe net benefits in
       some short enough time-frame after accounting for
       one-off purchase and installation costs) which are
       not only positive, but substantial and likely to
       attract many other end-users to the technology.
       For this to be true, the benefits received must not
       depend much or at all on what proportion of other
       users have adopted the technology.  Therefore, if the
       technology would be fundamentally attractive to many,
       most or all end-users once deployed by most or all
       end-users, it would also be attractive enough to the
       very first (or after some low, specified, level of
       adoption) to actually become widely deployed via a purely
       incremental means, without inducements or a major up-front
       deployment before any end-users gain significant benefits.

I think any map-encap scheme needs to meet the above criteria before
we could consider developing and deploying it.  (The above is what I
always thought was meant by "incrementally deployable", but I now
recognise this is much more stringent than what some or many people
meant by this term.)

  - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 1 Apr 2008 14:07:44 -0700

Robin,

>From: Robin Whittle [mailto:[email-masked]] 
>Sent: Tuesday, April 01, 2008 11:22 AM
>To: [email-masked]
>Cc: Templin, Fred L; Xu Xiaohu; Dino Farinacci; Noel Chiappa
>Subject: Re: [RRG] What does incremental deployment mean
>
>Hi Fred,
>
>You wrote:
>

ISATAP allows dual-stack nodes to discover routers that
can reach destinations on the global IPv6 Internet.

ISATAP is already widely implemented and deployed; in
many deployments it is even turned on by default.

Thanks - Fred

---

From: Robin Whittle <[email-masked]>
Date: Wed, 02 Apr 2008 10:36:42 +1100

Hi Fred,

> many deployments it is even turned on by default.

but it doesn't alter my understanding that it is not a solution to
the IPv4 routing scaling problem, because the only way it helps is
with hosts which are dual-stack and with applications which in fact
communicate via IPv6.

Also, ISATAP is a transition mechanism, requiring an IPv4 address.
So its only contribution to the IPv4 routing and addressing problem
would be to facilitate wide enough adoption of IPv6 that significant
numbers of end-users would be happy to have IPv6-only addresses,
with no IPv4 direct connectivity.  That won't I happen, I think,
until some very large proportion of hosts in general have IPv6
connectivity - 90%? 99%? 99.9%?

  - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 2 Apr 2008 07:47:17 -0700

Robin, 

>Sent: Tuesday, April 01, 2008 4:37 PM
>To: [email-masked]

The "domain of applicability" does not explicitly say
this, but dual-stack routers (or "hosts" that forward
packets on behalf of other nodes) are also within the
realm of application. That means that you can stack up
an arbitrarily large IPv6 network behind an ISATAP "host".

>Also, ISATAP is a transition mechanism, requiring an IPv4 address.

A private IPv4 address; yes. There are lots of those
available within end sites without impacting routing
scaling within the core.

>with no IPv4 direct connectivity.

No; not IPv6-only. Use address selection rules to
determine the appropriate address for use under the
appropriate circumstances. Sometimes that means IPv6
and other times that means IPv4.

Fred

>That won't I happen, I think,

---

From: David R Oran <[email-masked]>
Date: Wed, 2 Apr 2008 17:09:48 -0400

> From your summary, it sounds like any router changes are also very far
I'd either have to replace the router, or buy another box to be the  
*TR. However, that's a one box replacement scenario, which if it gets  
me multi-provider multihoming is a VERY strong motivator. In other  
words, as a site without easy access to PI space I get a big benefit  
for very little disruption/cost with an edge router solution.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Apr 2008 16:55:54 +1200

> id/locator split solution to address the IPv4 address depletion issue is

That's exactly what NAT does. We're trying to do better,
I believe.

   Brian

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 09 Apr 2008 10:37:29 +0200

> -----邮件原件-----
> 发件人: Brian E Carpenter [mailto:[email-masked]]
> 发送时间: 2008年4月9日 6:56
> 收件人: Xu Xiaohu
> 抄送: 'Randall Atkinson'; 'David R Oran'; [email-masked]
> 主题: Re: [RRG] What does incremental deployment mean
> 

Hi Brian,

My thought is:
The private addresses behind the NAT box are not suitable to be used as
identifier. However, these independent IPv4 address spaces can be used as
locator spaces as long as each private address space can be distinguished by
some means, such as globally unique locator space ID or the public IPv4 +
locally unique locator space ID. Then we can introduce a pure identifier
namespace, such as IPv6 or CGA address. In this way, most of the routers,
especially those in the site network, do not need to be upgrade to IPv6, and
the routing scalability issue and address depletion issue are solved
simultaneously. Of course, this requires some small change in hosts.

Is this approach more acceptable for site network owners compared with the
v6 EID over v4 RLOC LISP approach? It's easy for carrier to upgrade their
routers to IPv6, but it will be much hard for the site network to do this.

What's the better NAT solution in your mind?

Best wishes,
Xiaohu XU

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Apr 2008 09:21:20 -0700

Comments below:

>Sent: Wednesday, April 09, 2008 1:37 AM
>To: 'Brian E Carpenter'
>Cc: 'Randall Atkinson'; 'David R Oran'; [email-masked]
>> >> % So I can imagine it being reasonable to handle host changes on 
>> >> about % half of these. At best. And certainly not with a flag day 
>> >> just inside % my little orandom.net domain.
>> >>
>> >> From your summary, it sounds like any router changes are 
>also very 
>> >> far from being a given.
>> >
>> > id/locator split solution to address the IPv4 address depletion 
>> > issue is reasonable.
>> 
>> That's exactly what NAT does. We're trying to do better, I believe.
>
>Hi Brian,
>
>My thought is:
>The private addresses behind the NAT box are not suitable to 
>be used as identifier. However, these independent IPv4 address 
>spaces can be used as locator spaces as long as each private 
>address space can be distinguished by some means, such as 
>globally unique locator space ID or the public IPv4 + locally 
>unique locator space ID. Then we can introduce a pure 
>identifier namespace, such as IPv6 or CGA address. In this 
>way, most of the routers, especially those in the site 
>network, do not need to be upgrade to IPv6, and the routing 
>scalability issue and address depletion issue are solved 

Perhaps you would be interested in the idea of multiple nested
private IPv4 address spaces with IPv6 EIDs, where you would have:

  v6 EID -> v4 RLOC P1 -> v4RLOC P2 -> .. v4RLOC PN -> v4RLOC Global

In other words, map and encaps through N private spaces (P1 thru PN)
before a final (or after an intial) map and encaps through the global
IPv4 address space. The routers connecting the N nested private address
spaces are identified by an IPv6 prefix, e.g., with the nesting manifested
through IPv6 prefix delegation. This idea was put forth in the IPvLX proposal.

>v6 EID over v4 RLOC LISP approach? It's easy for carrier to 
>upgrade their routers to IPv6, but it will be much hard for 
>the site network to do this.
>

IPv6 routers that also serve as firewalls in front of a private
IPv4 address space?

Fred

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 09 Apr 2008 18:53:05 +0200

Hi Fred,

The concept of the nested address spaces is interesting, but I'm doubt the
driver for this network structure. BTW, there may be many private address
realm behind a NAT box, should there be a realm ID to distinguish them?

> IPv6 routers that also serve as firewalls in front of a private

IPv6 router you mentioned should be locator domain (space) border routers
(LDBR), these routers can support prefix-based routing and LD ID/LD prefix
based routing, and the internal routers within locator domain just need to
support IPv4 prefix-based routing. Of course, the firewall function can be
built into the LDBR if you like.

Best wishes,
Xiaohu XU

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Apr 2008 10:03:15 -0700

>Hi Fred,
>
>The concept of the nested address spaces is interesting, but 
>I'm doubt the driver for this network structure. BTW, there 
>may be many private address realm behind a NAT box, should 
>there be a realm ID to distinguish them?

An IPv6 prefix as a realm ID, maybe?

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Apr 2008 15:44:57 +1200

On 2008-04-09 20:37, Xu Xiaohu wrote:
> locally unique locator space ID. 

I don't think we want to set up yet another ID space and registry (see next
comment). I did just realise, reading draft-despres-v6ops-apbp-00.txt,
that when you're behind an IPv4 NAT, your transport ID is in fact
uniquely defined by {publicIPv4address, translatedPortNumber} - the
only problem being that this is known to the NAT and the other end,
but not to the "victim" of the NAT. Your network ID is uniquely defined
by {publicIPv4address, privateIPv4address} although nested NATs make
this more complicated.

> Then we can introduce a pure identifier
> namespace, such as IPv6 or CGA address. 

Indeed. Not using IPv6 as the globally unique address space would be
perverse in fact, since there is a complete registry and DNS support
for it already.

> In this way, most of the routers,
> especially those in the site network, do not need to be upgrade to IPv6,

Yes, but that upgrade is not an issue anyway - it's going to happen
as hardware replacement occurs.

> and

Well, changes that require application software upgrades are the hardest
of all. I don't see how to hide a change of ID space from applications.
> What's the better NAT solution in your mind?

draft-despres-v6ops-apbp-00.txt is too new for me to be sure,
but I think it gets rid of NAT64, and that is the best solution
of all.

    Brian

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 10 Apr 2008 12:45:53 +0200

> > locator spaces as long as each private address space can be
distinguished
> by

Let me clarify the idea of independent locator spaces. There are two
approaches to identify each locator space: 

The first one is to assign a globally unique LD ID to each locator space,
the LD ID is similar to AS no, but the LD ID is hierarchical and
aggregatable, e.g IPv4 address. This idea is borrowed from ENCAPS. However,
the AD ID in ENCAPS can not be aggregated since "the source and destination
addresses in the new header (I will call it the AD-Header from here on)
represent the source and destination Ads". That is to say, ENCAPS uses one
and only one tunnel between source and destination AD. In my idea of HRA, I
use segment-by-segment tunnels between adjacent LDBRs. LDBR implement LD
ID/prefix based routing, the internal IPv4 address within each locator
domain seems to be used as link-layer address.

The other one is to assign a local-scope unique ID to each private address
space behind a NAT box, the combination of the public IPv4 address of the
NAT box and the above ID will be used to distinguish each private address
space behind a NAT box. The latter approach looks like BGP/MPLS L3VPN and
there needs a core IPv4 network which is attached with a lot of private
address spaces. Once nested NAT is deployed, each successive NAT boxes will
need to implement ID->local locator mapping. This is the idea of IPNL.
However, IPNL uses FQDN as identifier.

> perverse in fact, since there is a complete registry and DNS support

Agree.

> as hardware replacement occurs.

My opinion is the replacement of site/enterprise networks will be much
slower than that of the carrier or ISP networks. Perhaps the enterprises
prefer upgrading their hosts other than upgrading their site networks.

> of all. I don't see how to hide a change of ID space from applications.

Since we introduce IPv6/CGA address as a pure identifier, the locator change
will be transparent to applications. So only host stacks but not
applications need to be upgraded based on the assumption that most of host
applications are IPv6-friendly.

> but I think it gets rid of NAT64, and that is the best solution

There are still some questions left for this APDP approach, including but
not limited to:
1) How can the IPv4-only hosts connect to the apbp-enabled hosts?  Let's
consider p2p model but not limited to client-server model.
2) How the apdp servers coordinate with each other for the failover purpose
since the apdp server needs to store states? Let's consider the IPv6
transition together with the popular phenomenon of multi-homing.

Best wishes,
Xiaohu XU