Subject: [RRG] A new draft about Hierarchical Routing Architecture

From: Xu Xiaohu <[email-masked]>
Date: Fri, 16 Nov 2007 12:11:07 +0100

Hi all,

I have just finished a draft about Hierarchical Routing Architecture (HRA),
which is also a kind of id/loc split solution. The following is an abstract
of HRA. 

Abstract: Hierarchical Routing Architecture (HRA) is a kind of id/locator
split solution. It introduces a hierarchical routing mechanism (a
combination of LD-based routing and prefix-based routing) to support routing
across multiple independent address spaces, besides, it also adopts a
hierarchical host identifier to ease the management of a global id/locator
mapping system. With HRA, the Internet routing scalability and stability are
improved evidently, and the scalability issue of flat HIT in HIP is also
solved, besides, the necessity of adopting IPv6 is also eliminated to some
extent as those locator domains can adopt overlapped IPv4 address spaces.

Sorry I missed the deadline of 00-version submission, so I have to attach
this draft in email. Any comments are welcomed.

Best regards,
 
Xiaohu Xu

---

From: Robin Whittle <[email-masked]>
Date: Fri, 16 Nov 2007 23:41:57 +1100

Hi Xu,

My first impression on reading over your HRA proposal is that it
involves changed host behaviour.

If this is the case, then I don't think HRA can be considered
alongside LISP, eFIT-APT, Ivip or TRRP - all of which are intended
to work for current and future hosts without any new host host
requirements.

I think HRA or any other system which requires host changes is
probably about as hard to introduce as IPv6: There seems to be no
strong enough immediate benefit for most early adopters to create
anything like widespread or ubiquitous adoption - and in the
meantime (~= forever) all ordinary Internet users still need full
IPv4 connectivity.

  - Robin

--
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: Fri, 16 Nov 2007 13:00:52 -0000

But there is quite a lot of v6 support in hosts, perhaps more so than in
networks? 

One of the tricks with migration is that there is a benefit to the
person who migrates. A crytpo ID gives potentially some security related
benefits (whether they are wanted or not is another question) therefore
there may be a motivation to add that to a host.

On the other hand, the tunnel proposals seem to require end sites (or
providers on their behalf) to do a lot of work so that the core routing
system can scale better?  

Louise

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Robin Whittle
> Sent: 16 November 2007 12:42
> To: Routing Research Group
> Cc: Xu Xiaohu
> Subject: Re: [RRG] A new draft about Hierarchical Routing Architecture
> 
> Hi Xu,
> 
> My first impression on reading over your HRA proposal is that 
> it involves changed host behaviour.
> 
> alongside LISP, eFIT-APT, Ivip or TRRP - all of which are 
> intended to work for current and future hosts without any new 
> host host requirements.
> 
> I think HRA or any other system which requires host changes 
> is probably about as hard to introduce as IPv6: There seems 
> to be no strong enough immediate benefit for most early 
> adopters to create anything like widespread or ubiquitous 
> adoption - and in the meantime (~= forever) all ordinary 
> Internet users still need full
> IPv4 connectivity.
> 
>   - Robin
> 
> 
> --

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 16 Nov 2007 17:42:23 +0100

> involves changed host behaviour.
Yes.

> to work for current and future hosts without any new host host
HRA should be looked as a long-term solution, like HIP or Node ID
architecture.

> meantime (~= forever) all ordinary Internet users still need full
It's something about the tradeoff between investment and benefit. The final
choice depends on the requirements of the future Internet service, e.g.
security, huge amount of address, end-to-end transparency principle for easy
deployment of new service.

Best wishes,
Xiaohu XU

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 16 Nov 2007 11:46:29 -0600

Thus spake [email-masked]
> But there is quite a lot of v6 support in hosts, perhaps more so than
> in networks?

The vast majority of hosts today have an IPv6 stack, with around half having 
it enabled by default and that'll rise to near totality within a few years.

ISP core networks also have IPv6 running, for the most part.  It's not 
generally pushed out to the edges, but that's more a matter of demand than 
capability these days.

The deployment problem is that most leaf networks, particularly the 
middleboxes at their borders, do not have IPv6 stacks or do not have them 
enabled.  The problem seems to afflict all leaf networks, whether consumers, 
content providers, enterprises, etc.

> person who migrates. A crytpo ID gives potentially some security
> related benefits (whether they are wanted or not is another
> question) therefore there may be a motivation to add that to a host.

It took a decade to get IPv6 implemented and on by default in Windows.  It 
is reasonable to expect it'll take a similar amount of time to get any other 
major host stack changes made and deployed.  We don't have that much time 
left, therefore solutions that require changes to host stacks are 
interesting but (IMHO) not useful at this point.

> On the other hand, the tunnel proposals seem to require end sites
> (or providers on their behalf) to do a lot of work so that the core
> routing system can scale better?

One of the major causes of core routing scalability problems is end-sites 
wanting PI space for multihoming or portability.  Currently, the cost of 
each PI prefix is paid by everyone _except_ the party that benefits.  LISP 
seeks to move the cost to the site that benefits without affecting anyone 
else: if you want PI space, you deploy an ETR and register your EID-to-RLOC 
mapping.  Who exactly deploys ITRs is an interesting question, but that's a 
fixed cost regardless of how many people deploy LISP, which makes the 
economics less challenging.  Since one would expect all ETRs to also be 
ITRs, if LISP is reasonably successful the ITR problem will mostly solve 
itself.

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: Tony Li <[email-masked]>
Date: Fri, 16 Nov 2007 10:59:29 -0800

On Nov 16, 2007, at 9:46 AM, Stephen Sprunk wrote:

> It took a decade to get IPv6 implemented and on by default in  
> Windows.  It is reasonable to expect it'll take a similar amount of  
> time to get any other major host stack changes made and deployed.   
> We don't have that much time left, therefore solutions that require  
> changes to host stacks are interesting but (IMHO) not useful at  
> this point.

Alternately, it's pretty clear that we're getting to the point where  
OS release updates are getting to be pretty well automated.  We can  
certainly expect that as we get large-scale experience with v6, we  
will find bugs with it, that those bugs will get addressed in service  
packs or similar updates.  It would seem that host vendors could also  
use the same mechanism to make changes to the host stack using their  
automated release process.

So, IMHO, changes to the host stack are still extremely viable.  It's  
true that they won't get overnight deployment, but then the router  
world is no longer deploying new code nightly either.

Tony

---

From: Mark Prior <[email-masked]>
Date: Sat, 17 Nov 2007 09:34:41 +1030

Stephen Sprunk wrote:

> generally pushed out to the edges, but that's more a matter of demand
> than capability these days.

I don't see evidence that deployment in the core is wide spread by any
stretch of the imagination. I think that this belief is an example of
the major disconnect between the operational community and the standards
one.

Mark.

---

From: Robin Whittle <[email-masked]>
Date: Sat, 17 Nov 2007 13:31:27 +1100

Hello Xu,

Thanks for your response.  I think there needs to be some
longer-term thinking in addition to the medium-term,
backwards-compatible, ITR-ETR schemes such as LISP, eFIT-APT, Ivip
and TRRP.

 - Robin

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 19 Nov 2007 12:46:11 +0100

----- Original Message -----
From: "Stephen Sprunk" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 16, 2007 6:46 PM
Subject: Re: [RRG] A new draft about Hierarchical Routing Architecture

> it enabled by default and that'll rise to near totality within a few years.

To quote from the v6ops list, which may or may not know something about IPv6
deployment,

>> So, the last point is most interesting - support the legacy customer
>> base. These are the customers who have not got devices that are dual-
>> stack or who are accessing services/servers that are not yet IPv6-
>> enabled. With 79% of the market running Windows XP (Net >>Applications
>> Oct 2007) we need to consider how to transition the bulk of our
>> customers to IPv6.
>
>If the concern is Windows XP, then we can devise specific solutions. >Windows
XP has some support for IPv6, but also has limitations. >Specifically, Windows
XP is not designed to run in an IPv6 only >environment. For example, it performs
name resolution over IPv4, and it >has only limited support for IPv6 literal
addresses. We can get a list of these >limitations, and draft from there the
minimal list of IPv4 functions that could >be placed in the network to make
things work. That could be an >interesting project.
>-- Christian Huitema

Tom Petch