[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Going forward with zero-config tunneling requirement
Erik, Pekka, All
It is true that some, me included,
find Isatap to be an adequate solution for 3GPP.
It is, however, not so that the 3GPP requirements/goals in zeroconf are
specified with Isatap in mind.
In any case not more so that in the complex process of distinguishing
nice-to-have from need-to-have things then one, of several, things that
you may squint at is what is known to be achievable, and in this respect
the features provided by Isatap is _one_ example of the latter.
But as the authors of zero-conf can testify then we have been extremely careful
with not adding something as a requirement simply because it is achievable - and
likewise the other way around.
The background behind the 3GPP requirements document, read zero-conf, is the following:
For some time now 3GPP has asked for the support of the IETF
to produce a standardised, solid tunnelling solution that
meets its needs.
Isatap has been identified by some as a potential solution,
and have been successfully deployed in
proto-type like 3GPP deployment environments.
Consequently people have pressed for the standardization of Isatap and
by standardisation here then I do not mean "rubber stamping" of the draft but
about qualified technical challenging, tie of loose ends, adjustments of possible
problems - all the things that the IETF normally do when making a "standard".
v6ops have been reluctant to do so, and the answer has been a mixture of the following:
* must wait until all scenarios have been considered, should find unified solution that fits all
* the requirements of 3GPP aren't clear - why do you think Isatap is good for you ?
* Isatap is limited, bad, not the right solution
Here it is probably important for me to emphasize that I absolutely agree that
finding one unified solution and/or limiting the solution space the best we can,
would be great, from a pure technical, from an implementation as well as from
a deployment perspective.
The problem we have, however, is the following:
No adequate standard has been produced which suits the needs of 3GPP and without a trusted and
consolidated IETF solution then in turn the transition scenario and its solution
space risk being completely written out of the 3GPP releases (to the extend that is hasn't already been suppressed
as a feasible and recommendable scenario).
Release 6 still include the transition scenario, but the absolutely HARD deadline
of this is November something. Furthermore, Ipv6 and Ipv6/Ipv4 transition 3GPP
deployment trials are starting up, the latter obviously also in need of
a solution, preferably a committed IETF solution.
Zero-conf aims to specify requirements of a simple tunnelling mechanism, which
would suit the needs of 3GPP (possibly also other scenarios).
Now that the requirements at least are written down,
the hope was this could facilitate and speed up the process towards finding a solution.
It has been discussed how to proceed from here and an attempted resolution was
to split the 3GPP requirements in one separate document and produce another one which would
detail the other scenarios needs in the area of zero-configuration tunnelling.
The objective of isolating the 3GPP requirements is not because the same
split is envisaged as automatically mapping over to the solution space. It is done
first and foremost because of the following:
* The timing requirements of 3GPP are very harsh and it was thought that we could not afford to loose time
by potentially blurring the requirements by the addition of various other aspects to the document.
That being said, it is clear, of course, that in order for us to be able knowingly to choose a solution which
applies not only to the 3GPP scenario, but also to e.g. the simple enterprise scenario, then the requirements work
of these other scenarios must move very fast too.
BR, Karen
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Erik Nordmark
> Sent: Thursday, September 30, 2004 9:37 PM
> To: Pekka Savola
> Cc: v6ops@ops.ietf.org
> Subject: Re: Going forward with zero-config tunneling requirement
>
>
> Pekka Savola wrote:
>
> > I was saying that with s/mechanism/requirements/
> >
> > I.e., having requirements in separate documents, allowing
> them to be
> > developed separately, does not mean that the solutions need to be
> > different. Similarly, if all the requirements for
> different scenarios
> > were in the same document, it wouldn't mean that one solution would
> > have to fulfill all the requirements.
>
> But you were excluding the "simple" from the assisted tunneling
> requirements, and I don't understand why. If this is all about
> allowing different communities needing to express their
> requirements in
> a separate document, then don't exclude things from the documents.
>
>
> > (Completely personal opinion below)
> > The critical thing will be whether the IETF 'honors' the 3GPP
> > deadlines for a [standards track] solution (November this year). As
> > you write, doing so would be very counterproductive. On the other
> > hand, it could be also considered practical and admitting
> the reality.
> > However, as such ISATAP will already go for Experimental
> RFC, so there
> > will exist some documentation to create interoperable
> implementations
> > in any case. There doesn't seem to be any particular reason to move
> > it to standards track just because of 3GPP.
>
> If the purpose of the 3GPP requirements is solely to convince the IETF
> that they will use ISATAP (which they might have already
> decided), why
> are we wasting time on a 3GPP requirements document?
> A requirements document makes sense when multiple answers are
> acceptable, but you seem to be saying that only one answer would be
> acceptable.
>
> I don't have a problem with an experimental RFC describing ISATAP as
> currently implemented, and perhaps a separate document describing its
> limitations.
>
> Erik
>
>