Re: CELP (was RE:)

[Dave Crocker <dhc@dcrocker.net>]

marcelo,

(my own comments below.  of course, avri might feel differently.)


mb> The Common Endpoint Locator Pool contains the locators of both endpoints
mb> involved in a communication.
mb> When a host A is communicating with a host B, the CELP of host A contains
mb> both locators from A and locators from B.

yes.


mb> Additionally, i  guess that the CELP has to contain reachability information
mb> about each locator (or perhaps about each locator pair, since a destination
mb> may be reachable or not depending on the source address used.)

Certainly the Internet has examples of pair-wise UNreachability. And
certainly there is concern that the Internet is moving towards more and
more of this partitioning. So as you note, a full model must account for
that reality.

However, I believe that early, simple versions of a CELP implementation
may choose _not_ to have pair-wise entries. As you note, there is a good
reason for maintaining locator pairs. However I would expect the simpler
approach to be adequate for many situations.

My point is that that simplifying assumptions are probably useful for
early adoption, in order to reduce the barrier to that adoption.


mb> Furthermore, some proposals also include information about whether the
mb> locator has been verified or not.

The fully-general version of a CELP implementation certainly can and
should maintain an extensive range of routing table classes of
information.


mb> There are three types of mechanism that can provide such information:
mb> - The enhanced transport layers
mb> - The wedge layer
mb> - The DNS

The 'DNS' reference probably should be something like "external lookup
services", with sub-entries, because mobility probably requires a more
dynamic Presence-like service.


mb> So, i am not so sure that a validated address means the same for the
mb> different mechanism, so i see a difficulty in including addresses through
mb> different means to be used by all of them.

Here, again, I see your point as being entirely correct for the
long-term theory of this approach, but I believe a much simpler model
can be used initially.

Where reality turns out to differ from this simpler model, a
conservative choice can be made, such as declaring unreachability. This
would be acceptable because the resulting, limited service is still much
better than what we have today.


mb> Clearly, the weaker mechanisms can benefit from addresses validated through
mb> stronger mechanisms but i doubt that the reverse would be possible. In any
mb> way, the first option is possible and it would help to reduce the overhead.

I think this depends on being able to characterise the different types
of validation, so that the practical meaning of "weaker" and "stronger"
validation have clear, operational definition and measurement. Only then
can we discuss the impact of the differences.


mb> The problem that has already been discussed in the list is that the timeout
mb> varies depending on the application.

This is a good example of the reason this topic is part IP-level and
part Transport-level. I've come to believe that it should be modeled as
a new, full-fledged architectural layer, taking some from IP and some
from IP and adding some new stuff.

At any rate, here again I think we can win with a simplied model
initially, for easier early adoption.  Then it can be enhanced.

(By the way, I hope it is clear that I'm not disagreeing with your
points. I think it is clear that all of them are correct. I'm only
suggesting a divide-and-conquor approach towards dealing with this
domain, where we defer whatever complexities we can, to gain early
utility. Then we can feed that experience into a later round of
enhancement.)


mb> Finally another question is how do identify a CELP is identified. I mean
mb> some wedge layer create new id name space, so you can just use the ID pair
mb> to identify the CELP, others don't introduce a new id name space, so regular
mb> ip addresses are used.

Well, the CELP discussion on granularity shows different sets of parameters
being used to identify different sets of locators.  The examples use IP
Address as the first level of discrimination.

I suppose the different identifiers are necessary for correlation during
maintenance activities. I'm not sure they actually affect _use_ of the
entries.


mb> Now the new id name space and the IP address space may collide, so a
mb> mechanism to uniquely identify a CELP is required.

collide?  huh?



d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>