[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tunneling scenarios and mechanisms evaluation
Hi,
I agree with Alain, that the way proto-41 fits. I'm not sure if we can call this NAT traversal, so may be rewording to NAT traversal or proto-41-forwarding ?
Regards,
Jordi
----- Original Message -----
From: "BAUDOT Alain FTRD/DMI/CAE" <alain.baudot@francetelecom.com>
To: "Pekka Savola" <pekkas@netcore.fi>; <v6ops@ops.ietf.org>
Sent: Friday, March 12, 2004 4:14 PM
Subject: RE : Tunneling scenarios and mechanisms evaluation
Hi,
Here are my few comments on the document:
1. Introduction
I think Tunnel Broker (TB) should part of the analysis, as well.
3.2 Unmanaged Networks
Case 2 seems to match ISP case 2a (where the connection network cannot be upgraded), unless it is a compilation of unman case C and ISP case 2a. Anyway, in one case the ISP cannot cooperate with unman network, while it can do so in the other case. The appropriate solution may then meet different requirements, e.g. oportunistic mechanism may or may be not suitable.
I guess this need some clarification.
"NAT traversal must be supported." This is not true if the tunnel ends in the gateway where the NAT function is usually located. I think this is important, since the solution to deploy does not need to deal with complexity of NAT traversal.
3.4 ISP Scenarios
"ISPs do not have specific scenarios which need to be addresses which
haven't been already mentioned"
ISP scenario case 2b, where the ISP backbone is not IPv6 capable, is not discussed here.
Anyway, I think that there is a large difference between "obtaining" connectivity, as discussed in the previous section 3.3, and "providing" a connectivity as an ISP. ISPs have strong requirements, at least, on user identification, in order to make sure the connectivity is provided to its customers with some reasonable load (and without unpredictable overload), and on addressing since the duly identified customer may benefit from some address/prefix delagation from the ISP' TLA.
4.1 Scenarios Evaluation
I think the matrix should match here all the identfied scenarios from 3GPP, UNMAN, ISP and ENT, and not a subset of them.
Two columns maybe added: one dealing with "user identification" and another one dealing with some prefix delagation means, in order to actually complement the ISP column.
4.2 Mechanisms Evaluation
I wonder here what is the real meaning of ISP support in terms of features or functions.
Anyway, to get a more compltete picture, I would add columns for:
-terminal/gateway: if the macnism applies to a terminal only, a gateway only or both
with the idea of complement ISP column:
-user identification
-address/prefix delegation means.
Regards,
Alain.
-----Message d'origine-----
De : owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] De la part de Pekka Savola
Envoyé : jeudi 11 mars 2004 09:14
À : v6ops@ops.ietf.org
Objet : Re: Tunneling scenarios and mechanisms evaluation
Whoops -- forgive my slip. The address below was where it WILL be
available. For now, it's at:
http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-tunneling-00.txt
Sorry -- and thanks to Tim for pointing the obvious! :)
On Thu, 11 Mar 2004, Pekka Savola wrote:
[...]
> http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-00.tx
> t
>
> Abstract
> This memo analyses the v6ops scenarios/analysis work (Unmanaged,
> 3GPP, ISP and Enterprise) for their requirements for tunneling
> solutions, and analyses the proposed mechanisms on how they might fit
> in these requirements, and discusses possibilities for choosing
> solution(s).
>
>
>
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
**********************************
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.