Subject: [rrg] A concern with ILNP//re: critique of RANGI

From: Xu Xiaohu <[email-masked]>
Date: Wed, 27 Jan 2010 09:36:49 +0800

Hi all,

In my attempt to answer Lixia’s question why using FQDN for ID and Locator lookup is a problem (see the following email), I occasionally found a doubt about ILNP. That is : how a legacy host continues the communication to an ILNP-aware host once the latter changes its locator due to mobility or re-homing event. Note that the legacy host is not that intelligent so as to resort the DNS to get the new locator of the ILNP-aware host.

Could someone please tell me which ILNP draft or paper describes the approach to the above issue? 

Best wishes,
Xiaohu

________________________________________
发件人: Xu Xiaohu [mailto:[email-masked]] 
发送时间: 2010年1月19日 15:33
收件人: 'Lixia Zhang'
抄送: 'RRG'; 'Paul Francis'
主题: re: [rrg] critique of RANGI

> -----邮件原件-----
> 发件人: Lixia Zhang [mailto:[email-masked]]
> 发送时间: 2010年1月19日 12:23
> 收件人: Xu Xiaohu
> 抄送: RRG; Paul Francis
> 主题: Re: [rrg] critique of RANGI
> 
> 
> On Jan 18, 2010, at 6:47 PM, Xu Xiaohu wrote:
> >> .....
> >> Hi Paul,
> >>
> >> I did not know that you were working on RANGI critique; as I
> >> mentioned
> >> to Xiaohu I could do one.
> >> So what I just did now is some minor additions to your text
> >> (1)pointing out that RAGNI ID is 24-byte long,
> >
> > No, RANGI ID is 16-byte long. The following is a demonstration of
> > the RANGI
> > ID.
> >
> >       |<------- n bits --------->|<-- 128-n bits-->|
> >       +--------------------------+-----------------+
> >       | Administrative Domain ID |   Local Host ID |
> >       +--------------------------+-----------------+
> >       |                            \
> >       |                              \
> >       |                                \
> >       |                                   \
> >       |                                      \
> >       +-----------+-------------+-------------+
> >       | Country ID| Authority ID| Region ID   | <------Example
> >       +-----------+-------------+-------------+
> 
> sorry, I missed the "-n" fine print :(
> In your RRG presentation at Hiroshima, the slide says n=64.  if that
> is still the case, then your local hostID would have the same length
> as ILNP EID (though the latter requires global uniqueness, and I
> suppose yours not)

Yes. To simplify the implementation, we use CGA as host identifier currently. Hence the value of n is set to 64.
 
> > (2)doing ID looking
> >> using DHT raises trust issue;
> >
> > In fact, we use the reverse DNS infrastructure as the id/locator
> > mapping
> > system, while the DHT is optionally used at the bottom level of this
> > infrastructure to make the authoritative server scale better.
> 
> The Hiroshima RRG talk showed the other way around ...
> 
> > This is my
> > assumption of a hierarchical DHT. IMHO, the hierarchical DHT doesn't
> > mean
> > DHT should be used in each level.
> 
> DHT is used for lookups for systems with very large number of entries.
> With a hierarchical system, where the bottom level is not that big, I
> wonder what is the value of using DHT in the first place.

I don't want to introduce too many levels in the hierarchy. Hence, in a given administrative domain (e.g., a state or a province), there may be a lot of entries to manage.

> I did not following the first sentence below (what do you mean by
> using "AD ID as a key"?)

A detailed example is given as follows:

1. An AD ID is expressed as "country-code.authority-code.region-code" by inserting dots between adjacent fields, then it is transformed into a FQDN format string as "region-code.authority-code.country-code".
2. The above FQDN format string is used as a key in the reverse DNS infrastructure to locate the corresponding authoritative server or the DHT ring for that AD. If DHT is used to scale the bottom-level authoritative name servers, the Local Host ID part is used as a key to locate the corresponding peer which stores the mapping of that identifier.
3. The Local Host ID part is used as a key to locate the matching mapping entry in the mapping table of the corresponding name server or the corresponding peer.

The following figure is a demonstration of the mapping system to be used in RANGI.

> > The structured AD ID is used as a key in the reverse DNS
> > infrastructure to
> > locate the corresponding super authoritative server (or the
> > corresponding
> > DHT ring when using DHT to make the authoritative server scale
> > better) which
> > maintains mappings for the identifiers belonging to that
> > Administration
> > Domain. If DHT is used to scale the authoritative server, the Local
> > Host ID
> > (flat label) is then used as a key in that corresponding DHT ring to
> > locate
> > the node which holds the mapping for that identifier. Hence, this
> > mapping
> > system has reasonable business model and clear trust boundaries.
> 
> Wonder if you have this described somewhere?
> I did not find it in http://tools.ietf.org/id/draft-xu-rangi-01.txt

Details about the id/locator mapping system will be included in that draft or described in a separate draft soon.

> >> .....
> >> RANGI critique
> >> ......
> >> More thought is
> >> needed as to what constitutes these levels, and what is the trust
> >> relation among the ID-Locator resolution servers that use DHT for
> >> lookup.
> >>
> >> The RANGI draft suggests FQDN->ID lookup through DNS, and separately
> >> an ID->locator lookup which may be DNS or may be something else.
> >> This
> >
> > Yes, the reverse DNS is used as an ID->locator mapping system in
> > RANGI, with
> > this approach there is no need for every host to have a unique FQDN.
> 
> this sounds like as if having a FQDN for each host a drawback?

Not sure whether it is a drawback. However, since there is already a global unique host identifier for each host in RANGI, which can be easily used for id->locator lookup, it seems no need to assign each host a unique FQDN.

> >> represents additional cost compared to ILNP design where FQDN lookup
> >> produces both ID and locators. Can one quantify the gain by one
> >> additional lookup to justify the cost?
> >
> > Yes, I know. However, ILNP design requires that every host should
> > have a
> > unique FQDN for ID and locator lookup.
> 
> could you elaborate what may be the problem with this as you see?

The reason I can thought why ILNP requires each host has a unique FQDN is: the flat EIDs to which the sessions are bound are not suitable for EID->Locator resolution, so another namespace (i.e., FQDN) is referred to.

My doubt is how a legacy host continues the communication to an ILNP-aware host once the latter changes its locator due to mobility or re-homing event. Note that the legacy host will not resort the DNS to get the new locator of the ILNP-aware host.

> >
> >> Unfortunately the early-adopter incentive for host upgrade strikes me
> >> as weak at best.
> >
> > We have the RANGI-PROXY [I-D.draft-xu-rangi-proxy-01] mechanisms
> > with which
> > legacy hosts could initiate communications to RANGI-aware hosts, and
> > vice
> > verse.
> 
> Is it fair to say that RANGI-PROXY is a similar idea to LISP's PTRs?

To be more accurate, the site proxy is similar to LISP ITR while the transit proxy is similar to LISP PTR.

Xiaohu

> I am trying to identify commonalities among proposals.
> 
> Lixia

---

From: Tony Li <[email-masked]>
Date: Tue, 26 Jan 2010 22:00:08 -0800

> In my attempt to answer Lixia’s question why using FQDN for ID and Locator lookup is a problem (see the following email), I occasionally found a doubt about ILNP. That is : how a legacy host contin…

A legacy host treats all ILNP hosts as simply other legacy hosts.  Thus, 
  an ILNP host that changes its locator and wishes to correspond with 
other legacy hosts must also change its IPv6 address (and AAAA DNS record).

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 28 Jan 2010 08:53:02 +0800

> -----邮件原件-----
> 发件人: Tony Li [mailto:[email-masked]]
> 发送时间: 2010年1月27日 14:00
> 收件人: Xu Xiaohu
> 抄送: 'RRG'
> 主题: Re: [rrg] A concern with ILNP//re: critique of RANGI
> 
> Xu Xiaohu wrote:
> > Hi all,
> >
> > In my attempt to answer Lixia’s question why using FQDN for ID and
Locator
> lookup is a problem (see the following email), I occasionally found a
doubt
> about ILNP. That is : how a legacy host continues the communication to an
> ILNP-aware host once the latter changes its locator due to mobility or
re-homing
> event. Note that the legacy host is not that intelligent so as to resort
the
> DNS to get the new locator of the ILNP-aware host.
> 
> 

Hi Tony,

However, when the ILNP host changes its locator during communicating with a
legacy host, even it updates its AAAA record in the DNS, the legacy host
will not resort to the DNS to get its new IPv6 address immediately after the
locator change. As a result, the already established session between them
will be broken. That's to say, ILNP can not support such a scenario where a
legacy host communicates to a mobile host (ILNP host).  Note that such a
scenario is supported in Mobile IP. By the way, even if the above ILNP host
is not a mobile host, but a fixed host located in a multi-homed site
network, the established session will also be broken when the site is
re-homed to another ISP. The basic reason is the transport association is
bound to one of the ILNP host's locators, rather than its identifier.

Xiaohu

---

From: Xiaoliang Zhao <[email-masked]>
Date: Thu, 28 Jan 2010 12:14:25 +0800

IMHO,

> is not a mobile host, but a fixed host located in a multi-homed site

is it a big concern? or in many cases, we just hang up and
redial/refresh page again? or transport layer (TCP) can be changed a
bit to do a better job to use identifier? I just don't see it as a
critical issue to ILNP...

Regards,
x.zhao

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 28 Jan 2010 12:33:52 +0800

> -----邮件原件-----
> 发件人: Xiaoliang Zhao [mailto:[email-masked]]
> 发送时间: 2010年1月28日 12:14
> 收件人: Xu Xiaohu
> 抄送: Tony Li; RRG
> > However, when the ILNP host changes its locator during communicating
with
> a
> redial/refresh page again? 

If so easy, then what's the meaning/motivation for Mobile IP?

> or transport layer (TCP) can be changed a

Binding transport associations to identifiers is a better choice. However,
like the home addresses in Mobile IP, the ILNP identifiers should also be
routable in the Internet so as to allow the packets with destination being
identifier to be forwarded to some home-agent like device. Then what's the
business model for deploying such home-agent like devices based on the fact
that the ILNP identifiers are flat. In addition, since the ILNP identifiers
are not required to be globally unique, routing based on such identifiers in
Internet is almost impossible.

Xiaohu

---

From: Tony Li <[email-masked]>
Date: Wed, 27 Jan 2010 23:28:20 -0800

Xu Xiaohu wrote:

> legacy host communicates to a mobile host (ILNP host).

In fact, ILNP isn't going to do much for a legacy host.  Period.  What
was your point?

> Note that such a
> scenario is supported in Mobile IP. 

So?  Use Mobile IP already then.

> By the way, even if the above ILNP host

See paragraph 1.

It's a legacy host.  It behaves like IPv6.  No better, no worse.

Upgrade already.  ;-)

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 27 Jan 2010 23:33:09 -0800

Xu Xiaohu wrote:

> 
> Binding transport associations to identifiers is a better choice. 

In other words, using an ILNP host would be better than using a legacy
host.  Yes, indeed.  I agree with that point.

> However,
> identifier to be forwarded to some home-agent like device.

You clearly missed the whole point: the identifier must be separated
from the locator, otherwise you have mangled semantics and you end up
back at LISP.  This is a poor architecture.  The whole point is to stop
compounding that original error.

> Then what's the
> that the ILNP identifiers are flat. 

There are no home-agent like devices in ILNP.

> In addition, since the ILNP identifiers

Exactly.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 28 Jan 2010 16:01:17 +0800

> 发送时间: 2010年1月28日 15:28
with
> > will be broken. That's to say, ILNP can not support such a scenario
where
> In fact, ILNP isn't going to do much for a legacy host.  Period.  What

OK, I got it. My point is the above scenario should be considered in a non-
clean-slate architecture.

> So?  Use Mobile IP already then.

Then each ILNP+ host should be assigned a globally unique home address just
for communication with legacy hosts ;) 

> It's a legacy host.  It behaves like IPv6.  No better, no worse.

Not better, but worse in some cases (e.g., the above scenario), IMHO.

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 28 Jan 2010 16:11:56 +0800

Hi Tony,

> 发送时间: 2010年1月28日 15:33
> 抄送: 'Xiaoliang Zhao'; 'RRG'

Yes, it is ideal to separate them clearly from a clean-slate point of view.
However, for incremental deployment purpose, I wonder whether the totally
non-routable identifier is a practical choice.

> There are no home-agent like devices in ILNP.

Yes, I know. It's just an assumption.

Best wishes,
Xiaohu

> > are not required to be globally unique, routing based on such
identifiers
> in

---

From: Tony Li <[email-masked]>
Date: Thu, 28 Jan 2010 00:15:18 -0800

> clean-slate architecture.

Not necessarily.  Some folks don't feel that it's necessary (or
beneficial) to warp the architecture around the legacy host.  Things do
change.  We no longer need to be concerned with our IMP number, for
example.  ;-)

Yes, we could have a band-aid architecture.  But then we have to live
with those band-aids.  Forever.  No thank you.

> for communication with legacy hosts ;) 

There's no such thing as ILNP+.  If someone wants to use an ILNP host
with Mobile IP to interact with legacy hosts, then yes, it will need to
act like a legacy host and have a home address.

> Not better, but worse in some cases (e.g., the above scenario), IMHO.

You haven't shown that.  All you've done is to restate that legacy hosts
can't take advantage of ILNP.  This was stipulated up front.  Asked and
answered.  Let's move on.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 28 Jan 2010 16:50:49 +0800

> 发送时间: 2010年1月28日 16:15

How many people used IMP, and how many people use current Internet? The
difference in scale may cause us to make totally different choices. ;)

Xiaohu

---

From: Tony Li <[email-masked]>
Date: Thu, 28 Jan 2010 01:37:40 -0800

> non-routable identifier is a practical choice.

This is the crux of the same debate that we've been having for three
years.  Are we trying to be incrementally 'easy'?  Or are we trying to
do it 'right'?

If we choose the path that's easy, then we end up in an architecture
that is not nearly as clean as we would like.

If we choose the path that's clean, then we have a deployment issue.

Note that if we can get to IPv6 at all (debatable), then we have an
existence proof that we CAN do wholesale deployment.

Thus, it would seem like there are two logical positions:

- Band-aids for IPv4.

- Clean fixes for IPv6.

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 28 Jan 2010 01:39:58 -0800

> difference in scale may cause us to make totally different choices. ;)

How many people WILL use the Internet in the next 40 years?  We've
reached about 1/7th of the world's population so far.

Why should the experience of 6/7ths of the world be constrained by the
architecture that we developed on IMPs?

Tony