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

[Xu Xiaohu <xuxh@huawei.com>]

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.
> 
> 
> 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.
If you don't use tree topology, you will have to adopt some LD-based routing
protocol to find a loop-free path.

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

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

> 
> Best regards,
> Simon
> 
> PS: I wonder a bit why your LDBRs are named NRs in the example of section
> 4.4.4? ;-)
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


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg