Hi Maria, all,
Let me clarify something. When I'm stating the
time-to-market issue for
L2TP, I mean versus other solutions.
We have evaluated the time-to-market scoring against how
much time ? (may be
everyone had in mind something that may not be the same for
all).
We have evaluated the time-to-market assuming that what we
discussed was
right (example, availability on this or that platform w/o
special additional
tricks, etc.).
Again, I'm not opposing to L2TP. I just want to be critic
and try to put the
criteria on a deeper level that what we did in Hong Kong.
May be the
criteria was not good enough (at least this is now my
opinion).
May be if we revise the criteria, for example TSP is better.
May be we need
to define how much time is "time-to-market"
because maybe 3 months is
impossible to have everything working in an integrated way,
and 6 months is
ok and is easier to match that with solution B instead of
with solution A.
What I'm asking is to make sure that the criteria is
objective. Which is not
the case right now in my opinion, because is slightly
generic.
What I'm asking is all the participants to express their
view, to understand
possible pros and cons.
If we want to reach a consensus we need a vast number of
folks speaking up
because they have invested some time to really evaluate the
situation.
Regards,
Jordi
> De: "Maria A. Dos Santos (mariados)"
<mariados cisco.com>
> Responder a: <mariadoscisco.com>
> Fecha: Thu, 9 Mar 2006 12:36:18 -0800
> Para: <jordi.paletconsulintel.es>,
<softwiresietf.org>
> Conversación: [Softwires] Notes and Consensus from
Interim Meeting in Hong
> Kong
> Asunto: RE: [Softwires] Notes and Consensus from
Interim Meeting in Hong Kong
>
>
>
>> -----Original Message-----
>> From: JORDI PALET MARTINEZ [mailto:jordi.paletconsulintel.es]
>> Sent: Thursday, 9 March, 2006 10:48
>> To: softwiresietf.org
>> Subject: Re: [Softwires] Notes and Consensus from
Interim
>> Meeting in Hong Kong
>>
>> Hi Ole,
>>
>> See below, in-line.
>>
>> Regards,
>> Jordi
>>
>>
>>
>>
>>> De: Ole Troan <otcisco.com>
>>> Responder a: <otcisco.com>
>>> Fecha: Thu, 09 Mar 2006 12:00:05 +0900
>>> Para: <jordi.paletconsulintel.es>
>>> CC: "softwiresietf.org"
<softwiresietf.org>
>>> Asunto: Re: [Softwires] Notes and Consensus
from Interim Meeting in
>>> Hong Kong
>>>
>>> Jordi,
>>>
>>> [...]
>>>
>>>> 3) There is no way to delegate an IPv4
prefix. This is not clearly
>>>> reflected in the actual problem statement,
but it was (there is a
>>>> missing paragraph that was asking for using
DHCP in the
>> same way as
>>>> DHCPv6). This can be easily resolved with a
DHCPv4-PD option. But
>>>> here again the time to market issue.
>>>>
>>>> 4) How IPv6 DNS parameter(s) is(are)
provided. Again time
>> to market.
>>>> May be there are other parameters that we
are also missing here.
>>>
>>> what makes these issues a problem that
softwires should
>> solve? i.e are
>>> there any requirement that is specific to
softwires with regards to
>>> DNS discovery and IPv4 prefix delegation?
>>
>> Yes, this disappeared, I guess by mistake, in the
last draft release.
>>
>>>
>>> I have always assumed the answer is
"no". that any provisioning
>>> mechanism which have been designed for
hardwires should
>> also be made
>>> to work on softwires.
>>
>> Agree, with the small difference that IPv4 and IPv6
don't
>> have the same features and here we need to appear
similar for
>> a good solution.
>>
>>>
>>> specifically to your points.
>>>
>>> DNS discovery: how to provide DNS parameters
over an IPv6 link is
>>> already specified in an RFC. an has multiple
>> implementations. in the
>>> softwire case you also have the option of using
the DNS discovery
>>> mechanism for the transport or the payload
protocol. I'm afraid I
>>> can't see which bit is missing here?
>>
>> The easy solution will be to use DHCPv6 when IPv6
is the
>> payload. I just don't agree with this extra piece
of code
>> being required in the clients. But also agree that
DNS is not
>> a big issue because you have IPv4 transport for
DNS.
>>
>> Not an issue on the reverse case.
>>
>>>
>>> IPv4 prefix delegation: IPv4 provisioning have
worked fine
>> for decades
>>> without prefix delegation... I can't see what
makes this
>> requirement
>>> special to softwires. if it is needed it should
be specified in the
>>> DHC WG.
>>
>> Agree, I'm not saying that doing so is softwires
work at all.
>> I'm saying is needed and should be done (in DHC
WG), but we
>> can't then say that the time-to-market for L2TP is
done.
>
> Jordi,
>
> There are definitely ways to do ipv4 DP today without
softwires
> in the picture. For instance, via the IPCP subnet mask
option,
> which is not a ietf standard (looks like it was
proposed as one
> http://quimby.gnus.org/internet-drafts/dr
aft-heinanen-ppp-subnet-00.txt
> )
> is being used in DSL solutions today. So if ISPs
choose to, the
> same can be used with softwires if ipv4 DP is needed.
I don't see
> why this will affect the L2TP softwire time-to-market
=( softwires
> just replace the hardwires, everything else stays the
same...
>
> alice
>
>
>>
>> As said, I think we need a much clear/detailed
criteria
>> before having a coherent decision.
>>
>>>
>>> /ot
>>
>>
>>
>>
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>>
>> Barcelona 2005 Global IPv6 Summit
>> Slides available 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.
>>
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwiresietf.org
>> http
s://www1.ietf.org/mailman/listinfo/softwires
>>
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Barcelona 2005 Global IPv6 Summit
Slides available 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.
_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires
|