Re: Shared Locator Address Pool (SLAP) protocol proposal

[Dave Crocker <dhc@dcrocker.net>]

Christian,

CH> This is very true. In fact, there are other advantages to transport
CH> approaches. The transport layer naturally obtains information on the
CH> quality of different paths.

In fact, I am suspecting that it will prove useful to distinguish -- and
modularize, and possibly even share -- the "quality assessment" function
in transport, from the other things such a protocol does.


>> 1. An endpoint runs Locator Pools (LP) as a resource shared among
>> different consumer services at the endpoint -- eg, a wedge layer
>> service and an enhanced transport service -- potentially with
>> multiple maintainers. (Yes, the latter raises a concern about
CH> In short, this would make the "wedge" a local concept in the host,

Not really. Each of these needs to exist in both the endpoints (or in
one endpoint and a proxy agent that is working on behalf of the other
endpoint.)

So each approach really is an end-to-end, cooperative service, rather
than being only a local to a single end, the way a typical NAT is.



>> Anyone from the various camps interested in discussing such an effort?
CH> We should not think in terms of "camps"... But, yes, I am interested.

Great!

As IETF proposal wars go, this one is -- so far -- pretty amicable. In
fact, I think it is proving extremely productive for getting a better
understanding of underlying issues.

But quite a few folks do have their favorite specification and are
lobbying for it. (Not just me. Not just the HIP folks.) On the average,
an IETF effort that seeks to "merge" competing proposals does not turn
out very well, but the current situation looks at least technically
reasonable to consider.


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