RE: [Softwires] Notes and Consensus from Interim Meeting in Hong Kong

["Bill Storer \(bstorer\)" <[e-mail]>]

Hi Jordi,

More responses inline.


Bill

> -----Original Message-----
> From: JORDI PALET MARTINEZ [mailto:[e-mail]] 
> Sent: Thursday, March 09, 2006 10:39 AM
> To: [e-mail]
> Subject: Re: [Softwires] Notes and Consensus from Interim 
> Meeting in Hong Kong
> 
> Hi Bill,
> 
> See below, in-line.
> 
> Regards,
> Jordi
> 
> 
> 
> 
> > De: "Bill Storer (bstorer)" <[e-mail]>
> > Responder a: <[e-mail]>
> > Fecha: Wed, 8 Mar 2006 13:45:11 -0800
> > Para: <[e-mail]>, <[e-mail]>
> > 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:[e-mail]]
> >> Sent: Wednesday, March 08, 2006 12:01 AM
> >> To: [e-mail]
> >> 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).

Regardless of whether NTT allows others to use their code or not, here's one large service provider who's implemented the softwires over l2tpv2 already.  Other SPs who want to play can port the available Linux code to XP.  If anyone's in such a hurry that they can't wait for a port, they can get a point6 box and hook it up between the XP machine and the IPv4 network.  


> 
> > 
> > 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.

The ISP issue is big.  Many ISPs are already managing large scale L2TPv2 implementations.  They know they can depend on it to be reliable and scale to large numbers.  It's taken them years to get to this point with L2TP.  Compared to implementing another protocol in their core, the effort to port an L2TP client to XP is small.   In addition, a large ISP rolling out an IPv6oIPv4 solution may want to produce their own client.  The effort of porting the L2TP source to XP could be done in parallel to the other client efforts.  So time to market wouldn't change much, if at all.  


> 
> 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
> ?

DHCP is the accepted standard for distributing information such as DNS parameters.  L2TP is a widely accepted method of providing vpn services. IPv6 devices are going to have to deal with these protocols regardless of softwires.  I don't think we want to deviate from a widely accepted standards to make a lighter weight client.  


> 
> > 
> >> 
> >> 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 <[e-mail]>
> >>> Responder a: <[e-mail]>
> >>> Fecha: Fri, 03 Mar 2006 12:01:29 -0600
> >>> Para: <[e-mail]>, Mark Townsley
> >> <[e-mail]>, "Durand,
> >>> Alain" <[e-mail]>, David Ward
> >> <[e-mail]>
> >>> 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-02SoftwiresInterimNotes.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
> >>> [e-mail]
> >>> https://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
> >> [e-mail]
> >> https://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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/softwires
> 

_______________________________________________
Softwires mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/softwires