Subject: Re: draft-palet-v6ops-tun-auto-disc-01.txt

From: Pekka Savola <[email-masked]>
Date: Sun, 1 Aug 2004 21:19:11 +0300 (EEST)

On Sun, 1 Aug 2004, Florent Parent wrote:
[...]
> My suggestion is that the client should not consider the IP address 
> discovered as being the tunnel endpoint, but instead let the tunnel setup 
> protocol do that.

That is up to the tunnel mechanism to specify.  Some could treat it as
the tunnel endpoint (if there is no negotiation: e.g., ISATAP, or
something like STEP).  Some others -- probably most -- require a
tunnel setup protocol, and then it isn't as much tunnel endpoint as
much the tunnel negotiation endpoint.  Note that in some cases these
could also be one and the same: the negotiation could happen
"in-band", inside the tunnel as well. (E.g., you'd actually "configure
a tunnel" towards the end-point, start sending v6 packets to
negotiate.)  But this all would depend on which kind of mechanism this
is applied..

> Other suggestion: Call it the "service endpoint" ;-)

"Tunnel service endpoint"?  No objection to that.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Florent Parent <[email-masked]>
Date: Sun, 01 Aug 2004 11:10:12 -0700

-- On Tuesday, July 27, 2004 08:56:03 +0300, Pekka Savola wrote:
...

>>
>> Thus my assumption that this document is targeted at the gap above is
>> correct. Then one should not be finding the best tunnel _endpoint_ but
>> the tunnel _service_ which can provide that endpoint. TSP for instance
>> does its own endpoint negotiation. Having a discovery method do that
>> would thus make TSP either be only for that single Tunnel Server or it
>> would require another step. The 'endpoint' wording thus is wrong IMHO
>> and should be resplaced by 'service'.
>
> Again, I disagree.
>
> Let's take TSP as an example as you mention it.  TSP has a great
> "gaping gap" (in your words): there is no way to discover the closest
> tunnel broker!
>
> For tunnel broker solutions, this document tries to address finding
> the tunnel broker end-point (where you can begin the negotiation).
> The tunnel broker negotiation specifies the ultimate endpoint where
> you'll build your tunnel (such address could of course be anycast or
> whatever as well).  What happens after getting the initial broker
> end-point it out of scope of this specification.
>
> For tunnel server solutions, this document tries to address finding
> the tunnel server end-point (where you can beging tunneling or
> negotiation, whatever the mechanism specifies).
>
> So, I have to disagree with you here.  We just want to discover the
> end-point.
>
> Any suggestions how to make it clearer?

If I read you correctly, you both agree on the tunnel broker model: A 
discovery mechanism will give you an IP address to connect to with the 
tunnel setup protocol, and this may or may not be the IP tunnel endpoint. 
This will be up to the setup protocol to decide, not the discovery 
mechanism.

On the tunnel server model, the discovery process can give you the tunnel 
endpoint IP address, but that is not certain. At least, using anycast for 
discovery, the client should be ready to accept and endpoint which is 
different from the IP address (anycast) used to discover the nearest 
"endpoint". I also think that this is dependent on the tunnel setup 
protocol used (which may support load-balancing/redirection).

Florent.

(rest of message cut)