Notes and Consensus from Interim Meeting in Hong Kong

Jordi,

to disable IPsec on windows 2000, found this link,
http://support.microsoft.com/default.aspx?scid=kb
;en-us;q310109 

This says it will allow user to run pure l2tp.

alice

> -----Original Message-----
> From: JORDI PALET MARTINEZ [mailto:jordi.paletconsulintel.es] 
> Sent: Thursday, 9 March, 2006 10:39
> To: softwiresietf.org
> Subject: Re: [Softwires] Notes and Consensus from
Interim 
> Meeting in Hong Kong
> 
> Hi Bill,
> 
> See below, in-line.
> 
> Regards,
> Jordi
> 
> 
> 
> 
> > De: "Bill Storer (bstorer)"
<bstorercisco.com> Responder a: 
> > <bstorercisco.com>
> > Fecha: Wed, 8 Mar 2006 13:45:11 -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
> > 
> > Hi Jordi,
> > 
> > Some responses inline.
> > 
> > Bill
> > 
> >> -----Original Message-----
> >> From: JORDI PALET MARTINEZ
[mailto:jordi.paletconsulintel.es]
> >> Sent: Wednesday, March 08, 2006 12:01 AM
> >> To: softwiresietf.org
> >> Subject: Re: [Softwires] Notes and Consensus
from Interim 
> Meeting in 
> >> Hong Kong
> >> 
> >> Hi all,
> >> 
> >> I want to make sure that everybody understand
the 
> importance of this 
> >> decision towards a consensus on this.
> >> 
> >> I'm not opposed to L2TP, actually during the
meeting, 
> before starting 
> >> the "framework" work, I was
convinced. But, the situation 
> changed on 
> >> the 2nd day when we formed a small group
looking more in deep on 
> >> this.
> >> 
> >> This is only my personal view, and not
necessarily from 
> this group, 
> >> but I guess others in the group can provide
their thoughts:
> >> 
> >> 1) The implementation status of L2TPv2 with
IPv6 support 
> for 85% of 
> >> the market is non-existent (XP). This is a big
concern for the 
> >> time-to market.
> >> It seems there is some solution from NTT, but
we need to 
> see if this 
> >> is publicly available (usage policy) or
instead if Microsoft will 
> >> provide it.
> > 
> >  
> > It's true that we don't have all the L2TP
support we need 
> for an "out 
> > of the box" XP solution.  However, L2TPv2
source code is 
> available for 
> > Linux.  All that's needed is for interested
services 
> providers to port 
> > the code to XP.  As you mention, NTT already has
an L2TPv2 solution 
> > for their XP customers.  Also, the Point6 box is
available 
> today as an L2TPv2 solution for XP users.
> 
> We need to check first if the NTT usage policy allows
anyone 
> to use it, and as I remember the web page for getting
it is 
> in Japanese, so not really useful. Probably NTT can
provide 
> an answer about this, and if this may be globally
available 
> at no cost in other languages, etc. Of course, as said,

> Microsoft can also change his mind regarding supporting
it in XP.
> 
> The Point6 solution, as I understand is not XP code, so

> doesn't work for me (we need time-to-market for the
bigger 
> market portion, which is XP, we like it or not).
> 
> > 
> > When talking about time to market it's important
to remember the 
> > widespread implementation of L2TPv2 in the service
provider 
> > environment.  It's been shown to scale well, be
reliable and 
> > manageable.  Waiting for multiple service
providers to 
> implement another protocol would be a time to market
issue.
> 
> Agree, is a difficult situation. Both sides need to
work: 
> Clients need to have support and also ISPs.
> 
> However, when we evaluated, in the meeting, the
criteria, we 
> write too fast what is the real support available, and
only 
> realized it afterwards. Even still not 100% clear, at
least for me.
> 
> Time to market from TSP, right now, seems to me much
better 
> than L2TP from the client side. I know I can download a

> client for all the platforms and that it works ALL the
time, 
> with any NAT box. But ISPs don't have TSP support 
> implemented, just a very few.
> 
> However, looking from the ISP side, they have L2TP but
not 
> with IPv6 support most of them. It could be easy, may
be, but 
> is that meaning 3 months or 12 months ?
> 
> > 
> >> 
> >> 2) In most of the implementations using IPsec
seems also 
> mandatory, 
> >> again time to market, in a practical
perspective, is broken.
> > 
> > As mentioned before, there is a registry setting
to turn off Ipsec 
> > with L2TP in Windows.
> 
> Ok, but this is trick that a regular user will not be
able to play ...
> 
> Anyway, if you know it, please, let us know and we can
start 
> playing ourselves at least ! The result of playing with
it 
> can help to take the decision ...
> 
> > 
> >> 
> >> 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.
> > 
> > A quick google search shows there are dhcpv6
clients 
> available for Windows XP.
> > 
> > http://klub.com.pl/dhcpv6/

> 
> Yes, I know, but it means adding more pieces of
software to 
> the client, which means (from my point of view) a
decrease in 
> the "time-to-market"
> scoring. The question is how much this weights :-(
> 
> We had already a long discussion some time ago which is
very 
> relevant for PDAs, cellular devices, embedded devices,
etc. 
> They have memory and CPU problems and requiring more
code may 
> be a handicap.
> 
> If there are some stats about how much cost, in terms
of 
> bytes, a DHCPv6 implementation in different platforms,
that 
> will be very useful.
> 
> Same question for L2TPv2 and L2TPv3.
> 
> May be comparing that against the cost of TSP, can
bring some 
> light to this ?
> 
> > 
> >> 
> >> 5) It seems that encapsulation in UDP is
forced. I don't 
> really agree 
> >> with this, as I already expressed my concerns
about that 
> also in the 
> >> problem statement work.
> > 
> > Certainly true for L2TPv2, but it's never been a
problem 
> for existing 
> > L2TPv2 scalability.  And as we mentioned, it's
optional for L2TPv3.
> > 
> 
> I think is sub-optimal to force UDP, but the positive
thing 
> here is that this will be improved when we move to
phase 2 
> with L2TPv3.
> 
> > 
> >> 
> >> Not sure if I'm missing anything else. This
is what I meant during 
> >> the meeting with more in deep discussion about
the 
> decision criteria, 
> >> which actually was never presented for
discussion to the WG.
> >> 
> >> So, what others believe ? Can we live with all
this, or is not so 
> >> clear now that L2TP may be not the best
solution ?
> >> 
> >> Regards,
> >> Jordi
> >> 
> >> 
> >> 
> >> 
> >>> De: David Ward <dwardcisco.com>
> >>> Responder a: <softwires-bouncesietf.org>
> >>> Fecha: Fri, 03 Mar 2006 12:01:29 -0600
> >>> Para: <softwiresietf.org>, Mark Townsley
> >> <townsleycisco.com>,
"Durand,
> >>> Alain" <Alain_Durandcable.comcast.com>, David Ward
> >> <dwardcisco.com>
> >>> Conversación: Notes and Consensus from
Interim Meeting in 
> Hong Kong
> >>> Asunto: [Softwires] Notes and Consensus
from Interim
> >> Meeting in Hong Kong
> >>> 
> >>> All -
> >>> 
> >>> Many thanks to all that participated in
the interim
> >> meeting. We accomplished
> >>> a lot of work and achieved consensus on
selecting our
> >> solution technology
> >>> for both hub and spokes and mesh
scenarios. Also many
> >> thanks to Spencer
> >>> Dawkins who performed scribe duties (and
managed to keep
> >> his laptop going
> >>> after a perilous fall from his desk) and
our hosts, CUHK
> >> and CERNET. David
> >>> also provided note taking duties as well. 
Dah Ming Chiu
> >> from CUHK and
> >>> Jiaping Wu from CERNET provided us meeting
rooms, internet
> >> access, all local
> >>> logistical coordination, local
transportation and local
> >> meals. It should be
> >>> noted that the meeting was the first
official IETF meeting
> >> in China and that
> >>> we demonstrated that it is easily possible
to have a 
> successful and 
> >>> productive meeting!
> >>> 
> >>> 
> >>> Here is the location of the meeting
minutes:
> >>> 
> >>> http://bgp.nu/~dward/softwires/2006-02SoftwiresI
nterimNotes.html
> >>> 
> >>> Please send me any corrections before I
submit them to the
> >> secretariat. I
> >>> will update them as appropriate.
> >>> 
> >>> 
> >>> Here is a summary of what the participants
achieved
> >> consensus and our set of
> >>> deliverables and next steps:
> >>> 
> >>> Consensus Summary:
> >>> 
> >>> 1 H&S scenario: L2TPv2 chosen as the
immediate solution,
> >> L2TPv3 in phase 2
> >>> 2 Mesh scenario: Conjoined effort for
extensions to MPBGP
> >> based on work
> >>> presented by Chris Metz and Yong Cui
> >>> 
> >>> 
> >>> Deliverables (docs to be made WG docs):
> >>> 
> >>> General docs:
> >>> (The names below lists the suggested
authors by the WG
> >> chairs and interim
> >>> meeting participants. All are welcome to
participate)
> >>> 
> >>> 1 Security analysis (delivered July 2006
IETF) - Florent, 
> Shu, Carl
> >>> 2 Radius accting (delivered July 2006
IETF) - Laurent, Bruno
> >>> 
> >>> Mesh:
> >>> 1 Framework doc using MPBGP (delivered
July 2006 IETF) - 
> Chris, Yong
> >>> 2 Multicast draft  (delivered March 2006
IETF) - Greg,
> >> Dino, Jiaping Wu,
> >>> Xing Li
> >>> 3 Extensions (delivered July, Nov 2006
IETF)
> >>>     1     tunnel-safi
> >>>     2     softwire connector
> >>>     3     softwires attributes
> >>> 
> >>> Hub and Spoke:
> >>> 1 Phase 1 Framework doc using L2TPv2
(delivered July 2006 IETF) - 
> >>> Jean-Francois, Bill, Laurent, Alice, Jordi
> >>> 2 Phase 2 Framework doc using L2TPv3
(requirements and
> >> progress discussed at
> >>> post-July '06 interim meeting, delivered
Nov 2006 IETF)
> >>> 3 Extensions (discussed next interim
meeting, delivered Nov
> >> '06 IETF, March
> >>> '07 IETF)
> >>>     1     DHCP
> >>> 
> >>> Proposed Agenda for Dallas Meeting - David
and Alain
> >>> 
> >>> 1     Report from the Interim Meeting
> >>> 2     Hubs and Spokes: Phase One L2TPv2 as
selection and
> >> framework overview
> >>> 3     Mesh: BGP-MP as selection and
framework overview
> >>> 4     General documents the working group
needs to take on
> >>> 5     Next Steps and Phase 2 work
discussion
> >>> 
> >>> NOTE: Please send us other agenda slot
requests
> >>> 
> >>> Given that consensus was achieved between
the participants
> >> of the interim
> >>> meeting, we are calling for comments on
the list so that we
> >> can claim WG
> >>> consensus.
> >>> 
> >>> Here is the final draft of the Problem
Statement that will
> >> be submitted
> >>> immediately (we made some terminology
tweaks during the
> >> interim meeting):
> >>> 
> >>> 
> >> http://bgp.nu/~dward/softwires/draft-ietf-softwire
-problem-sta
> >> tement-01.txt
> >>> 
> >>> 
> >>> Again many thanks to all participants in
the meeting and
> >> our local hosts.
> >>> 
> >>> -DWard, Alain
> >>> 
> >>> 
> >>>
_______________________________________________
> >>> 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
> >> 
> 
> 
> 
> 
> **********************************************
> 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
> 

_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires