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

From: "Bill Storer \(bstorer\)" <[email-masked]>
Date: Wed, 8 Mar 2006 13:45:11 -0800

Hi Jordi,

Some responses inline.

Bill 

> -----Original Message-----
> From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
> Sent: Wednesday, March 08, 2006 12:01 AM
> To: [email-masked]
> 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.

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.  

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

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

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

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

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 09 Mar 2006 19:39:24 +0100

Hi Bill,

See below, in-line.

Regards,
Jordi

> De: "Bill Storer (bstorer)" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 8 Mar 2006 13:45:11 -0800
> Para: <[email-masked]>, <[email-masked]>
> 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 
> 
> 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 ?

> As mentioned before, there is a registry setting to turn off Ipsec with L2TP

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

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

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

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.