RE: CELP (was RE:)

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Dave,

i agree with your divide and conquer approach and providing simple
mechanisms initially as a mechanism to facilitate adoption.
Moreover, it has to be considered that initially neither applications nor
transport (multiaddress capable or not) will be able to fully benefit from
CELP since some explicit communication between CELP and transport/wedge
layer are required for this i guess.

The point then i guess would be to agree on which points can be delayed and
which points are required even for a simplified initial version.

I will try to comment on this below....


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

I am not sure that this would be good enough.

I mean, the source address used by multihomed sites implies at least the
return path and in many scenarios also the forward path (because of the
ingress filtering)

So, if you don't consider the source address when determining whether a
destination address is reachable, you are basically omitting the fault
tolerance capabilities of multihoming.

Suppose a multihomed site with two ISPs, ISPA and ISPB. Each of the
providers has delegated a prefix to the multihomed site, PA and PB.

A host H1 within the multihomed site is communicating with a host H2 outside
the multihomed site, H1 is using PA:H1 address and H2 has only one address
H2.

Now the link between the multihomed site and the ISPA fails.

Then H2 is reachable using PB:H2 but H2 is not reachable using PA:H1

Bottom line is that if the source address is not considered, fault tolerance
capabilities of multihomed are not present, i think.



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

I think i didn't explain myself very properly in the previous posting, sorry
for the unclear statement.

When i said verified, i was talking about the security verification.

My understanding is that first the host learns a set of locators.
Then it verifies them using some security mechanism, in order to avoid
impersonation, flooding etc.
Finally it verifies the reachability of the locators.

In this part i was talking about the security verifications, that's why the
stronger and weaker language.

Some wedge approaches use pretty strong security mechanism, such a public
key crypto.
Some transport solutions just use a cookie, which may be acceptable because
only a connection is at stake

Then, what i meant is that i don't think that a locator verified by the
transport mechanism will be acceptable for the wedge layer.

However, it may be acceptable in the other case around, i.e. a locator
verified with PK crypto can be accepted by a solution that relies on
cookies.

I hope i have explain my concern in a better way this time.

About the simplified initial approach, i am not sure if this would be
possible here either.

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

This is the point where i think that an initial simplified model could be
more possible.
If one app marks an address pair as unreachable, no matter what unreachble
means to the app, may be a simple initial start point.

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

I agree with your approach

[...]

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

This is just an implementation detail, i guess.

But if a wedge layer uses the Hash of the FQDN as the permanent identifier
(just to take a random example :-) and the transport layer uses the regular
IP address to identify the other endpoint, you have to make sure that these
two don't have the same value for different hosts, because if this happens
you will have the same identifier for two different hosts when accessing the
CELP, but i may be missing something... In any case, i don't think this is
unsolvable

Regards, marcelo

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