[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tunneling scenarios and mechanisms evaluation


On Mar 12, 2004, at 12:13 AM, Pekka Savola wrote:

Section 4.3:
    Therefore we get that Teredo and STEP is the lowest common
    denominator, after having to take a few tough issues in the
    consideration, with Teredo and TSP coming somewhat behind.

Is there a typo here? Teredo is listed twice. 

This is intended.  Based on the analysis, the requirement for Teredo
exists no matter what else we choose.  The most preferable solutions
in addition to Teredo, however, seemed to be STEP and TSP.

Ok, then it just that the sentence is a bit confusing, as you were looking at
4 tools, I thought that 2 of them were 'preferable' and the other 2 were 'not so preferable'



2)
This draft makes a big issue about direct connectivity and bases
the some underlying recommendations on this.

let me ask: is this really a requirement or yet another nice to have?
What will break without direct connectivity? (in any of the scenarios)


When your ISP doesn't offer IPv6 connectivity, but you would have to
take a "long leg" to get it, it seems that to be able to achieve
anything useful (e.g., peer to peer connectivity), direct connectivity
is a real requirement.

On the other hand, when your ISP/operator is offering IPv6
connectivity, in my eyes it is *not* a strict requirement (and not
reflected as such in the analysis), because the extra leg that needs
to be taken is probably in the order of 1-10 ms, not 30-300 ms.  The
former is still usable, the latter not.

The length of the 'long leg' may vary. Even if your ISP does not provide you
with a tunnel server, this does not mean that you have to go to Canada
to get one! If this model is successful, there will be a good chance that
somebody near you could offer tunnel service.
I can even see that as a commercial argument to incite people to switch ISP!
This is an economic/deployment issue, not a protocol issue.

If nothing really breaks, but things are just sub-optimal, then I
would say this is not that bad. remember that we are talking about
transition mechanisms, they DO NOT NEED to be perfect, if not we
will never deploy fully IPv6... So, in a certain sense, suboptimal
transition mechanisms can be good in the long run ;-)


I agree that I don't (personally) think direct connectivity is a
requirement, for reasons you state, when your ISP/operator is offering
the tunnel service.  I'm not sure which context you're discussing, but
if you're saying that direct connectivity is not a requirement in the
cases where your ISP is not offering a service, then I would have to
disagree due to concerns of scalability for large-scale deployment.


Please elaborate on this point.  If  your ISP does not help but
a neighboring ISP offer v6 tunnels, what is the problem?

Note: With regard to TSP, we are not in a situation of take it or
leave it. If the ban on developing tools is lifted, I'm convince
that we could design something very quickly if the detail analysis
of TSP shows improvement are necessary.

Such ban does not exist,

In practice it does exist. TSP, for example, did not have the same amount of review,
collaborative work as a individual submission as if it would have been a wg item.


and IMHO it is clear that TSP (or the model
in general) requires a lot of improvement -- I reviewed it some time
ago, and sent feedback on the list.  So far that I'd rather start from
scratch, while keeping the model intact..  But this is something that
would be very quickly doable, if we want to do it.

Agree. Let's do it.


3- Isatap is really interesting in sparse deployment, which are
early scenario. If this wg takes another 4 years to look at it, then
its value would have long been depreciated...

Did you mean s/really interesting/really only interesting/?

Yes, typo.

The benefit of ISATAP is providing direct tunneling between the nodes.
This may be interesting in sparse deployment (compared to
going dual-stack; but in sparse deployment, tunnel server is also
fine), and some have even expressed interest in dense deployment
(compared to dual-stack: not wanting to go there; compared to tunnel
server: not overloading the server).  IMHO, the dense deployment
scenario calls for dual-stack, and we should not be hacking to work
around that.. and sparse deployment can be facilitated by a tunnel
server.  So, personally, I'm not sure if I see much applicability in
direct connectivity in this specific "ISP-assisted" context.

Agreed, I have said for about 4 years now that one could use an internal TB
to do this.



5)
what about the others, like 6to4? Do we still need this despite the
issues with the relays?


Unfortunately, I think yes -- in the unmanaged case where there is no
ISP support ...


Well, if there were deployed 'neighborhood' TB that works well, the need
for 6to4 will be somehow lower.

- Alain.