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

From: Xu Xiaohu <[email-masked]>
Date: Tue, 20 Nov 2007 16:57:47 +0100

Hi all,

These days I have received some feedbacks and questions publicly or
privately. Thanks those people for their valuable comments at first. 

For better understand of HRA, I want to do some clarification about it here:

First, the globally unique HIT within HRA plays the role of host identifier
actually, whereas the variable-length HI (the public key) is just used for
security purposes such as encryption and authentication.

Second, the hierarchical HIT within HRA is in accordance with the characters
of an ideal endpoint identifier described in Noel's endpoint namespace
draft, such as global uniqueness, Topological Insensitivity, Portability,
partially "Local Creatability", Distributed Catalogueabilty, Embedded
Organizational Affiliation and Fixed Length. Besides, it's a cryptographic
host identifier, and it can be used as a part of secure Internet environment
for the purpose of e-commerce healthy development. Take mobile phone as an
example, you don't feel inconvenient at the age of no mobile phone, but once
you use it, you will find you can not leave it almost. I believe the
cryptographic host identifier has some kind of character like mobile phone.

Third, the hierarchical global locator namespace (a combination of LD ID and
local locator) meets the demand of huge addresses in future Internet at a
minimum cost. It has no influence on most of routers except LDBRs,
especially from the perspective of forwarding plane. We don't need to suffer
the dilemma of IPv6 transition anymore.

Fourth, the hierarchical routing mechanism meets the new requirement of
routing stability in [draft-irtf-rrg-design-goals-01], as a route churn in
one LD will not be flooded in the whole Internet.

Lastly, HRA also does some effort from the perspective of deployability.
Most of routers except some LDBRs are not required to be replaced or
upgraded. Besides, Hierarchical HIT and hierarchical DHT ease the management
of the global id/loc mapping system and global uniqueness guarantee
mechanism.

Any comment is welcomed.

Best regards,
 
Xu Xiaohu

--
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: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 23 Nov 2007 18:01:15 +0100

On Tue, Nov 20, 2007 at 04:57:47PM +0100,
 Xu Xiaohu <[email-masked]> wrote 
 a message of 51 lines which said:

> privately.

Apparently, your draft was not submitted? I do not find it in the
official repository, only in your initial message. I suggest to submit it.

> Take mobile phone as an example, you don't feel inconvenient at the
> age of no mobile phone, but once you use it, you will find you can
> not leave it almost. I believe the cryptographic host identifier has
> some kind of character like mobile phone.

The relationship between the deployment of mobile phones and
cryptographic identifiers is a complete mystery to me...

> Any comment is welcomed.

The security section certainly requires more time and effort. I've
seen many ID/loc proposals and there is a common structure: the author
has a new idea (often a variation of existing ideas), post the draft
without security analysis, find that their proposal is much better
than any other proposal, and, when they try to add security in their
proposal, they discover that their proposal becomes as complicated and
difficult as the others.

Security is often the Achille's heel of ID/loc separation. Every
indirection is a new failure point.

---

From: xuxiaohu 41208 <[email-masked]>
Date: Sun, 25 Nov 2007 17:18:26 +0100

Hi Stephane,

Thanks for your comments. See in line please.
> official repository, only in your initial message. I suggest to submit it.
The cut off time for the I-D submission was 9 AM (ET), 2007-11-19. 
The I-D submission tool will be reopened at midnight, 2007-12-03, so I have to submit it after Dec 3.
> cryptographic identifiers is a complete mystery to me...
Maybe that example is not much proper. But what I want to say is some technology can create a new market opportunity.
> indirection is a new failure point.
Definitely agree. It's a common requirement for every id/loc split solution to take mapping registration/distribution security into account. 

Best wishes,
Xiaohu Xu

---

From: "Simon Schuetz" <[email-masked]>
Date: Mon, 26 Nov 2007 13:42:05 +0100

> -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]] On Behalf 
 > Of Xu Xiaohu
 > Sent: Friday, November 16, 2007 12:11 PM
 > To: 'Routing Research Group list'
 > Cc: 'Tony Li'; [email-masked]
 > Subject: [RRG] A new draft about Hierarchical Routing Architecture
 > 
 > 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: "Simon Schuetz" <[email-masked]>
Date: Mon, 26 Nov 2007 14:37:02 +0100

Hi Xu,

Sorry for sending an empty message before.

I've been reading your draft and have a couple of comments.

First of all, your HRA looks quite similar to what is defined in the Node Identity Internetworking Architecture, or NIIA like it's shortened on this list.
It also employs loc/id split with cryptographic host identifiers, has the notion of locator domains (LDs) and has borders routers (LBDRs/NRs) to bridge between the locator domains. Routing is also based on a two-level routing - identifier-based routing across LD borders and locator based routing within one LD.

The main difference is that HRA already prescribe running an LD based routing protocol. Unfortunately, the routing protocol is not described in the current draft version. NIIA is in it's simplest form built on a registration based routing scheme, but is open to run other (LD-based) routing protocols as well.
A second difference is that you allow a hierarchical host identity tag.

HRA suggests to put destination-host locators into the packets, already starting from the source host. IMO, this is problematic for the following reasons:
a) If you employ an LD schemes, the destination's locator has no meaning for the source host if source and destination belong to different LDs
b) How should the field in the protocol be dimensioned if you don't know in advance which underlying networking technologies will be used, i.e. you might not know the size of the locator.
c) If the source host has to retrieve a destination host's locator from DNS or any other lookup system, then this information needs to be updated in the global lookup system for every locator change of the end-host. If it is e.g. based on DNS, DNS needs to be updated for every movement that implies an IP address change.

What's the main reason for putting the destinations locator into the packet?

Some comments on the comparison section of HRA and NIIA:

> 1) Within the NIIA, there should be a stable core LD, and all the 
>   other LDs should be connected to the core LD directly or indirectly. 
>   Most of the traffic will go across the core LD. While within HRA, 
>   there is no limitation on the topology, that is to say, those LDs 
>   within HRA can be connected in mesh."

NIIA assumes a (rather) stable core LD (like e.g. todays IPv4 backbone network), which gives some stability to the architecture. However, it still allows different LDs to be connected in a mesh structure. Traffic only has to go across the core LD if there is no better route known. The idea in NIIA is, if you don't know where to go, go to the core LD and you will find your way.

>   2) Within the NIIA, as the network topology is tree-based, there 
>   seems no need to run a LD-based routing protocol. Besides, the NR use 
>   host-based routing mechanism which means a potential scalability 
>   issues if LD contains a lot of hosts. While in HRA, LDBRs exchange LD 
>   reachability information and support LD-based routing mechanism. 

It is nowhere stated in the NIIA draft that topology has to be a tree. Basically, LD structure can be anything. 
It is true that the registration based (default-) routing as described in the draft leads to tree-like structures, but alternative routes are still allowed. The paths build-up by registrations should however create a DAG (directed acyclic graph), it does not need to be a tree. Section 3.4.2 of the NIIA draft discusses effects of multihomed hosts and networks.

Running an LD-based routing mechanism inside NIIA would also be perfectly fine, it was just excluded from the first architecture draft for simplicity.

>   3) Within the NIIA, the existence and characteristics of connectivity 
>   between two locator domains, especially the edge locator domains, may 
>   change dynamically on relatively short timescales, due to routing 
>   changes, mobility or multi-homing events. LD mobility triggers host 
>   within the mobility LD to update the registration, especially when 
>   the CER is changed, that's to say, the LD mobility is not fully 
>   transparent to the host. Within HRA, the connectivity between locator 
>   domains is relatively stable and the mobility of partial network in 
>   LD still depends on the NEMO [RFC3963] like mechanism, and network 
>   mobility is transparent to those hosts within mobile network. 

What do you mean with CER?
Whether a mobility event is transparent to an end-host in NIIA depends on the type of mobility. If a whole LD moves, and the NR takes care of updating the hosts' registration on behalf of them, then the mobility is fully transparent to all hosts in that LD.

Best regards,
Simon

PS: I wonder a bit why your LDBRs are named NRs in the example of section 4.4.4? ;-)

 > this draft in email. Any comments are welcomed.
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 26 Nov 2007 17:35:58 +0100

Hi Simon,
Thanks for your comments firstly. Please see in line.
> 
> First of all, your HRA looks quite similar to what is defined in the Node
> Identity Internetworking Architecture, or NIIA like it's shortened on this
> list.
> It also employs loc/id split with cryptographic host identifiers, has the
> notion of locator domains (LDs) and has borders routers (LBDRs/NRs) to
bridge
> between the locator domains. Routing is also based on a two-level routing
-
> identifier-based routing across LD borders and locator based routing
within
> one LD.
In HRA, inter-LD routing is based on LD ID, but not identifier. This is
different from the behavior of NR within the NIIA.

> The main difference is that HRA already prescribe running an LD based
routing
> protocol. Unfortunately, the routing protocol is not described in the
current
> draft version. 
BGP extension with a new address family is the easiest way to fill this
need.
I will describe the details in next version.

>NIIA is in it's simplest form built on a registration based
> routing scheme, but is open to run other (LD-based) routing protocols as
well.
I believe so, but as the LD connectivity within NIIA is relatively dynamic,
so NIIA should support adjacent NR discovery and dynamic LD-based routing
session establishment, it looks some difficult. :)  

> A second difference is that you allow a hierarchical host identity tag.
Correct, we want to ease the management of a global mapping system and
improve the lookup efficiency with this hierarchical HIT concept. The
hierarchical HIT has Distributed Catalogueabilty and Embedded Organizational
Affiliation features. Optionally, the administrative domain ID can be taken
as LD ID of the registration LD, which is routable in HRA.

> HRA suggests to put destination-host locators into the packets, already
> starting from the source host. IMO, this is problematic for the following
> reasons:
> a) If you employ an LD schemes, the destination's locator has no meaning
for
> the source host if source and destination belong to different LDs
Yes, but destination locator has meaning for the LDBR of destination LD.

> b) How should the field in the protocol be dimensioned if you don't know
in
> advance which underlying networking technologies will be used, i.e. you
might
> not know the size of the locator.
If IPv6/IPv4 coexists within HRA, the locator field should have some
locator-type field to identify the type of the following locator. If each LD
uses independent IPv4 address space, there would be no need for that
locator-type field.

> c) If the source host has to retrieve a destination host's locator from
DNS
> or any other lookup system, then this information needs to be updated in
the
> global lookup system for every locator change of the end-host. If it is
e.g.
> based on DNS, DNS needs to be updated for every movement that implies an
IP
> address change.
Basically yes, but hierarchical mobility management mechanism in [RFC4140]
can also be borrowed into HRA to reduce the amount of registration updates
between the mobile host, its correspondent hosts, and its mapping server.
For example, we can use LDBR as a registration proxy.

> What's the main reason for putting the destinations locator into the
packet?
The purpose of carrying destination locator in packets is to avoid the LDBR
of destination LD performing HIT->locator mapping lookup, which will result
in packet loss or latency for the initial packets in case that cache is used
in LDBR. As the LD within HRA is relatively large in size, the LDBR can not
store all mapping info for all hosts within that LD.
> NIIA assumes a (rather) stable core LD (like e.g. todays IPv4 backbone
network),
> which gives some stability to the architecture. However, it still allows
> different LDs to be connected in a mesh structure. Traffic only has to go
across
> the core LD if there is no better route known. The idea in NIIA is, if you
don't
> know where to go, go to the core LD and you will find your way.
If you don't use tree topology, you will have to adopt some LD-based routing
protocol to find a loop-free path.

> It is nowhere stated in the NIIA draft that topology has to be a tree.
Basically,
> LD structure can be anything.
> It is true that the registration based (default-) routing as described in
the
> draft leads to tree-like structures, but alternative routes are still
allowed.
> The paths build-up by registrations should however create a DAG (directed
> acyclic graph), it does not need to be a tree. Section 3.4.2 of the NIIA
draft
> discusses effects of multihomed hosts and networks.
Up to now, I just see registration based routing mechanism in your draft and
other NIIA related paper and slides. :(

> Running an LD-based routing mechanism inside NIIA would also be perfectly
fine,
> it was just excluded from the first architecture draft for simplicity.
I believe so. Especially, it will be helpful to adopt LD-based routing
mechanism in the core to support multiple core LDs coexist within NIIA. It
would be more scalable and more flexible in that way.

> Whether a mobility event is transparent to an end-host in NIIA depends on
the
> type of mobility. If a whole LD moves, and the NR takes care of updating
the
> hosts' registration on behalf of them, then the mobility is fully
transparent
> to all hosts in that LD.
In HRA, I take those hosts in mobile network as a whole, network mobility
event just trigger one registration update. But I think this would not be
the fact in NIIA.

> PS: I wonder a bit why your LDBRs are named NRs in the example of section
Such a careful reader. Maybe the guy who provides this figure for me is
poisoned deeply by NIIA. ;-)

Thanks for your valuable comments again.

Best wishes,
Xiaohu XU

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 28 Nov 2007 09:47:01 +0100

Hi,

Now I can provide a link to the HRA document.
http://www.huawei.com/file/download.do?f=3073

Any comment is welcomed.

Best regards, 
Xu Xiaohu

> -----邮件原件-----
> 发件人: Stephane Bortzmeyer [mailto:[email-masked]]
> 发送时间: 2007年11月23日 18:01
> 收件人: Xu Xiaohu
> 抄送: 'Routing Research Group'
> 主题: Re: A new draft about Hierarchical Routing Architecture
>