Subject: Tunnel Discovery

From: "Bound, Jim" <[email-masked]>
Date: Thu, 4 Nov 2004 08:05:28 -0500

Appears to me we have a few specs doing tunnel endpoint discovery or
automation of tunnels.  At this point I think we need to see if we need
one document.  Two I reviewed are below:

draft-palet-v6ops-solution-tun-auto-disc-01.txt

The above has good uses cases but I am not clear DNS should be used in
the manner suggested operationally.

draft-ietf-v6ops-assisted-tunneling-requirements-01.txt

The above is approaching the problem correctly and a good piece of work.
And also a good vechicle to documet the various issues and opportunities
for work.

Does the working group believe tunnel discovery is important to automate
or have means to set up policy or do we leave to the market, given all
other work we have to do?  I don't know right now?

/jim

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 04 Nov 2004 15:56:23 +0100

Hi Jim,

The idea behind those two works are to be complementary.

One specify the requirements for assisted tunneling, while the other one is
the result of the analysis document (draft-palet-v6ops-tun-auto-disc), to
specify how the TEP (used by different mechanisms, all those that do
tunneling), should be discovered.

We need to decide if this is applied only to TBs, for example (so the users
don't need to manually look for the TB via Google or whatever), or if is
applicable (or at least open) to be used also by other mechanisms.

Today most of the mechanism use a default TEP, but is not usually the best
one, and can be configured via a change in a configuration file, command
line, or whatever.

Our understanding is that it will be nice if the same mechanism, an
automatic one (that of course can be overridden), could be used by all the
mechanisms, and moreover, not requiring any modification of those
mechanisms, but being activated before the mechanisms itself.

We are working in documenting a little bit more this part, because is not
complete enough in the document right now. I hope we can have some new text
next week already.

For example, today only 6to4 does it, via anycast, but this is not the best
solution, as we know. That's why we decided to use DNS SRV RR, after
analyzing all the possible existing solutions (to avoid a new mechanism),
and anycast as a last resort backup (in case when the ISP doesn't provide
the service to their customers, they can still find some services available
outside, as today we do with 6to4, or simply if the ISP prefers to use
directly anycast instead of DNS SRV RR for whatever reason).

One more step is to document the usage of the same mechanism to discover not
only 6in4 TEPs, but also 4in6 ones, as we believe that will be nice (and
possible) to have a single one for any x-in-x encapsulation.

Regards,
Jordi

> De: "Bound, Jim" <[email-masked]>
> Responder a: [email-masked]
> Fecha: Thu, 4 Nov 2004 08:05:28 -0500
> Para: <[email-masked]>
> Asunto: Tunnel Discovery
> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Alain Durand <[email-masked]>
Date: Thu, 04 Nov 2004 10:35:25 -0800

>the manner suggested operationally.

There is also:
http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service-discovery-00.txt

>And also a good vechicle to documet the various issues and opportunities
This one is a requirement document, not a solution one..

>other work we have to do?  I don't know right now?
IMHO, this is/should be on the critical path of this wg.

    - Alain.

---

From: "EricLKlein" <[email-masked]>
Date: Fri, 5 Nov 2004 20:06:33 +0200

Is there an interest in an off WG consolidation of these 3 into one or at
most 2 complementary documents that the WG would then review?

draft-yamamoto-naptr-service-discovery-00.txt
draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
draft-palet-v6ops-solution-tun-auto-disc-01.txt

Sitting where I am in the NMS/OSS arena having these defined cleanly would
make my work much easier, so I would be consider helping with this.

Eric

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Nov 2004 22:19:42 +0200 (EET)

> draft-palet-v6ops-solution-tun-auto-disc-01.txt

Umm.. isn't the middle one orthogonal to the other two?  There are 
likely some requirements for tunnel endpoint discovery in the middle 
one, yes, but that could not be merged in a solution.

(extremely personal view below)

More work towards the common solution is probably good, but personally 
I'm still quite a bit unconfortable with the fact that we have not 
analyzed the properties of different approaches -- in 
palet-v6ops-tun-auto-disc -- in a sufficient manner.  It seems 
premature to jump on to the solution space (especially with naptr 
approach which I'm personally most uncomfortable yet, at least).

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