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

From: "Bill Storer \(bstorer\)" <[email-masked]>
Date: Thu, 9 Mar 2006 13:48:35 -0800

Hi Jordi,

More responses inline.

Bill

> -----Original Message-----
> From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
> Sent: Thursday, March 09, 2006 10:39 AM
> To: [email-masked]
> Subject: Re: [Softwires] Notes and Consensus from Interim 
> Meeting in Hong Kong
> 
> 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 
> > 
> >> -----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.
> 
> 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 <[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
> >> 
> 
> 
> 
> 
> **********************************************
> 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: JF Tremblay <[email-masked]>
Date: Thu, 09 Mar 2006 18:03:44 -0500

Inline.
Sorry for the slightly out-of-order editing, this thread is getting 
quite long, so some paragraphs were reordered for the sake of clarity.

<snip>

>> >> when we formed a small group looking more in deep on this.

I do share Jordi's opinion on this.

For sure, when putting up the scores for L2TP, that 100% seemed pretty 
convincing. But after more scrutiny, some aspects were obviously not 
debated in details, time-to-market being the most obvious one. Even 
David agreed that it's not realistic to put 100% for L2TPv2.

Time to market is mentioned in the abstract and the introduction of the 
problem statement as the single most important criteria for the 
solution. When asked for this to be put as a separate criteria, the 
answer from one of the co-chair was that "time-to-market will be 
considered as part of every single critera". As far as I can tell, in 
the end, time to market for the different solutions wasn't really 
debated during the interim.

<snip>

>> > providers to implement another protocol would be a time to

<snip, and a bit of reordering>

>> most of them. It could be easy, may be, but is that meaning 3

Agreed, there are large L2TPv2 deployments in the field. However, how 
many end users actually use L2TP for IPv6 access? I don't remember 
seeing any number on this. The numbers that matter are the actual 
deployments numbers that apply to the softwire context.

>> support implemented, just a very few.

There are also commercial implementations of TSP by third parties 
specifically for ISPs. These implementations can be purchased today.

> (we need time-to-market for the bigger market portion, which

Agreed. Point6 is also not a commercially supported implementation, 
most ISPs would not use it.

> >> actually was never presented for discussion to the WG.

IMHO, the bottom line is this: we skipped some steps in the evaluation 
of the criteria and of the protocols at the interim meeting.

Don't get me wrong here, I'm not necessarily asking for the end 
decision to be changed. I only wish for the evaluation of the protocols 
to be performed with the appropriate level of scrutiny so that in the 
end, everybody is convinced we made the right choice (which doesn't 
seem to be the case now).

I suggest that as a wg item in Dallas, we do review the list of 
criteria used in the grid. Time-to-market is obviously a criteria that 
should be added to the list. Then we could perform an in-depth review 
of the issues that have been raised about different protocols, review 
the scoring and take the best decision.

My 2 (canadian) cents.

Jean-Francois Tremblay
Hexago
-------------------------------------------------
http://www.freenet6.net : Free IPv6 Connectivity
-------------------------------------------------
"Computer Science is no more about computers than
astronomy is about telescopes" - E. W. Dijkstra
-------------------------------------------------

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 10 Mar 2006 08:30:19 +0100

> 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

Yes, but if you compare that with how many implemented TSP, the difference
can be very big. Regardless, I don't really think we want to consider what
is already there, because that could lead to a decision of let's use what is
already being use by most of them, even if it is the worst protocol. Note
that I'm not saying that this is the case for TSP. I'm saying that we need
to look into the protocol benefits altogether with the time-to-market.

BUT, we need a more concrete definition of time-to-market which affects all
the technical criteria issues.

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

Sorry, that's not time-to-market. We have been clear when working in the PB
statement all the time, and during the last two years that should be
available as an easy+inexpensive solution which users, w/o technical
knowledge can download. So a NTT-like solution I guess (I have never tried
it) could make it, but one more box can't (at least for most of the users).

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

I could agree on this, but if we verify it. For example, during the meeting
I suggested talking to Microsoft to know if they would change their plans
regarding supporting IPv6 on XP L2TP.

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

Agree, IF the implementation cost is feasible in all the platforms. Let's
look into how many bytes all this code takes, so we can make an informed
decision !

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.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 10 Mar 2006 08:50:01 +0100

> debated during the interim.

I think part of the problem is that we never discussed in the WG the
criteria. That was probably a wrong step, and the reason to have this
discussion post-meeting, which I'm sure would have been more effective in
the other way around.

> deployments numbers that apply to the softwire context.

It seems that only NTT users. It will be nice to know how many, but as said
before, are we going to choose something because some already deployed it,
regardless of having a better choice ? Is not our business to choose the
protocol with better usage stats, unless is much better and the
time-to-market for the others is, let's say, terribly worst.

> specifically for ISPs. These implementations can be purchased today.

I'm referring here to the server side (SC). For the client, I'm convinced
that TSP is much better in terms of time-to-market (even if I don't like
using XML !).

> the scoring and take the best decision.

Will agree on this if we define the criteria much better NOW !

---

From: David Ward <[email-masked]>
Date: Fri, 10 Mar 2006 10:48:22 -0600

> discussion post-meeting, which I'm sure would have been more effective in

We posted the criteria before the meeting and discussed it at the interim
meeting. I am not sure what you mean by the above statement. The process was
followed as one should expect.

-DWard

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 10 Mar 2006 18:18:02 +0100

Hi David,

Not really, at least in my opinion (and seems that I'm not alone). The
criteria was posted in a very short time before the meeting, but it was not
designed by the WG. The WG was not asked to provide inputs about this
criteria or suggested changes (as I can remember).

During the meeting we didn't clarified what exactly is time-to-market, and
as a consequence we only realized about the mistake the 2nd day, when the
groups started to work on each specific issue.

Anyway, discussing this now will not be helpful. We may need to update the
criteria and make everything clear so the complete WG reach a consensus. I
think that's what is relevant now.

Regards,
Jordi

> Responder a: <[email-masked]>
> Fecha: Fri, 10 Mar 2006 10:48:22 -0600
> Para: <[email-masked]>, "[email-masked]" <[email-masked]>,
> David Ward <[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
> 
>

---

From: David Ward <[email-masked]>
Date: Fri, 10 Mar 2006 11:40:39 -0600

For the record, the official request for comments to the WG was on Feb 08,
2006 with the criteria actually posted in Jan. The criteria are a direct
restatement of the MUSTs in the problem statement which the WG directly
created. There were no additional items added by the WG chairs that are not
discussed in the PS draft.

-DWard

On 3/10/06 11:18 AM, "JORDI PALET MARTINEZ" <[email-masked]>
wrote:

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 10 Mar 2006 19:07:56 +0100

Yes, this was the exact text:

"Please review the agenda, logistics information and Criteria for Solution
Set selection. The last item is a draft following discussions that Alain,
Mark and myself have had over the last weeks. It is an effort to guide
presenters on what we expect to see/hear and a way for the WG to select
candidate solutions. What you will find is a separation of technical and
non-technical items that should be addressed. The technical items are
derived from the MUST requirements from the problem statement and the
non-technical items are rather generic questions that fall into the
categories of concern that we have discussed as a WG."

It shows that it has been prepared by 3 people, not the WG. The WG is not
requested to take a position or provide inputs on this and it proved that
was not good enough. Specially because the lack of concretion in what means
exactly TTM.

Again, no need to keep going on this. I just insist in all the WG
participants to take a position. Specially let's define what is TTM.

Regards,
Jordi

> Fecha: Fri, 10 Mar 2006 11:40:39 -0600
> David Ward <[email-masked]>, "Durand, Alain" <[email-masked]>