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

From: "DENG, HUI -HCHBJ" <[email-masked]>
Date: Sat, 4 Mar 2006 04:00:16 +0800

SSBqdXN0IG1lbnRpb24gb25lIHRoaW5nIGluIGNhc2UgZnV0dXJlIG1pc3Rha2UgaGFwcGVuLA0KIA0KPkl0IHNob3VsZCBiZQ0KPm5vdGVkIHRoYXQgdGhlIG1lZXRpbmcgd2FzIHRoZSBmaXJzdCBvZmZpY2lhbCBJRVRGIG1lZXRpbmcgaW4gQ2hpbmENCkNoaW5hIE1vYmlsZSBhbHJlYWR5IGhvc3RlZCBJRVRGIExlbW9uYWRlIFdHIEludGVyaW0gTWVldGluZywgSmFuIDI1dGgsIDIwMDYsIEJlaWppbmcNCmh0dHA6Ly93d3cxLmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbGVtb25hZGUvY3VycmVudC9tc2cwMTkwOS5odG1sDQogDQotSHVpDQo=Disclaimer:The contents of this e-mail, and its attachments, if any, are confidential and may be protectedby law against any unauthorized use.  If you have received this e-mail by mistake or havereason to believe that you are not the intended recipient, please notify the sender by replye-mail as soon as possible and delete it from your computer system immediately thereafter.If you are not the intended recipient, you must not copy this e-mail or attachment or disclosethe contents to any other person.  While we have made every effort to keep our network virus free,we take no responsibility for any computer virus which might be transferred by way of this e-mail.

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

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Thu, 9 Mar 2006 11:24:38 -0800

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:[email-masked]] 
> Sent: Thursday, 9 March, 2006 10:39
> 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).
> 
> > 
> > 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 <[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
> >>> 
> >>> 
> >> **********************************************
> >> 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.
> >> 
> >> 
> >> 
> >> 
> **********************************************
> 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.
> 
> 
> 
>

---

From: "Gray, Eric" <[email-masked]>
Date: Fri, 10 Mar 2006 17:16:12 -0500

Alain,

	Actually - as much as possible - we want the people who
are implementing the technology to directly influence those 
that are writing the specifications.  In some cases, it would
be ideal if the two groups were the same (and this has been
the case at least a few times in the past).

	As part of the philosophy of "running code", we do not
first write specifications and then ask people to implement
them...

--
Eric

--> -----Original Message-----
--> From: Durand, Alain [mailto:[email-masked]] 
--> Sent: Friday, March 10, 2006 3:27 PM
--> To: [email-masked]
--> Subject: RE: [Softwires] Notes and Consensus from Interim 
--> Meeting in Hong Kong
--> 
--> > -----Original Message-----
--> > From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
--> 
--> > Specially let's 
--> > define what is TTM.
--> 
--> Softwires is an IETF wg. This is not a vendor consortium, not an ISP
--> one,
--> and this is not a technology evangelism group.
--> The -only- thing we are tasked to do is write specs and it 
--> will be other
--> people's job
--> to implement them and yet others to deploy them.
--> 
--> So, as an IETF wg, if we want to -formally- define Time To Market,
--> the only thing we can do is define it as the the time it will
--> take this wg to complete its tasks.
--> 
--> In other words, it means looking at the availability of the complete
--> suite of
--> standard specifications necessary to build interoperable products
--> (including MIBs! ), the IETF status of the said standards
--> (i.e ID, experimental RFC, Standard track RFC),
--> and the availability of two independent interroperable 
--> implementations
--> of every single components needed to advance along the 
--> standard track.
--> 
-->    - Alain, Sowtwires wg co-chair.
--> 
--> 
--> _______________________________________________
--> Softwires mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/softwires
-->

---

From: "Durand, Alain" <[email-masked]>
Date: Fri, 10 Mar 2006 18:14:21 -0500

No objection to that, of course!

    - Alain. 

> From: Gray, Eric [mailto:[email-masked]] 
> Sent: Friday, March 10, 2006 5:16 PM
> To: Durand, Alain
> Cc: [email-masked]
> Subject: RE: [Softwires] Notes and Consensus from Interim 
> Meeting in Hong Kong
> 
> Alain,
> 
> first write specifications and then ask people to implement them...
> 
> --
> Eric
> 
> --> Hong Kong
> --> one, and this is not a technology evangelism group.
> --> The -only- thing we are tasked to do is write specs and 
> it will be 
> --> other people's job to implement them and yet others to 
> deploy them.
> --> 
> --> the only thing we can do is define it as the the time it 
> will take 
> --> this wg to complete its tasks.
> --> 
> --> suite of standard specifications necessary to build interoperable 
> --> products (including MIBs! ), the IETF status of the said 
> standards 
> --> (i.e ID, experimental RFC, Standard track RFC), and the 
> availability 
> --> of two independent interroperable implementations of every single 
> --> components needed to advance along the standard track.
> -->

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 15 Mar 2006 14:41:01 -0500

Chair hat off, someone-who-works-for-a-large-service-provider hat on.

As servide provider, it is critical to have a solution that
is deployable in today's core networks.

The client side of the story is always fixable via software download,
the server side must be fully serviceable. That means, multiple vendors,
scalable products, MIBs,... People who do not work for large service providers
often have a tendancy to underestimate those aspects.

The discussion last week was centered on the client side, and I agree that
lack of clients would have been an issue, but accordind to what I read,
this is not the case. The server side is IMHO a much more important issue.

   - Alain. 

> From: Fiumano, Michael F [NTK] [mailto:[email-masked]] 
> Sent: Wednesday, March 15, 2006 2:06 PM
> To: [email-masked]
> Hello,
> Why do all solutions "require" Windows at all???  I have the 
> need to use this standard to enable a port on my network to 
> tunnel v6 over my v4 infrastructure to a v6 enabled part of 
> my network.  I hope that this is being kept in consideration 
> for the solution space.
> 
> As an operator of a large network, the problems I see aren't 
> always from a end host.  I would prefer an L2TPv3 solution 
> preferably as we use this technology today as a L2 psuedowire 
> transport across our network. 
> 
> Maybe I am off base, and this is not being given any 
> attention because it is assumed that this will work, but 
> please consider this when talking to your solutions as well.
> 
> Thanks,
> Michael Fiumano
> Senior Network Engineer
> IP Core Infrastructure
> 703-689-5875 Wk
> 703-598-2434 Cel
> [email-masked]
> 
> 
> 
> 
> > Fecha: Wed, 15 Mar 2006 08:54:46 -0800
> > Para: "Maria A. Dos Santos (mariados)" <[email-masked]>, 
> > <[email-masked]>, <[email-masked]>
> > To summarize here:
> > 1. None of the proposed solutions are supported by standard 
> issue "out 
> > of the box" Microsoft Windows.  All of the solutions will require 
> > loading extra software on Windows.
> 
> I'm not sure if this was a requirement, not in my opinion. It 
> will be ideal, but we know is difficult for old OSs.
> 
> > 2. L2TP is closest in the above sense as it is supported by 
> standard 
> > Windows XP for IPv4/IPv4 tunneling.
> 
> With a small trick to disable IPsec, but I guess it could be 
> automated.
> 
> > 3. GPL code is available for L2TP.
> 
> Same as other solutions.
> 
> > 4. L2TP has been implemented in Windows by NTT and SixXs.
> 
> It will be by SixXS, but agree, within a good timing in my 
> opinion (actually shorter timing that I will say is the 
> required one, but that's a different discussion).
> 
> > 5. Most importantly, L2TP is widely supported by the major 
> > concentrator vendors.
> 
> Yes, for two main router/concentrator vendors, should be ok.
> 
> > 
> 
> Now, if you compare L2TP with TSP (I'm not advocating for one 
> or the other, just trying to analyze the situation), TSP 
> seems better to integrate from the client perspective and no 
> need to play tricks in any OS. However has less support from 
> the server side.
> 
> So the question is again, IF we want to have a fair comparison:
> 1) Technical detailed comparison of different aspects among 
> both of them, pros and cons (i.e., overhead, prefix 
> delegation, DNS, etc.).
> 
> 2) How much time it will take for router/concentrator vendors 
> to implement TSP, and if it will happen in case we choose it.
> 
> 3) How much weight we give to the support in routers vs. the 
> support in clients.
> 
> Not easy ...
> 
> > 
> > Bill
> > 
> >> From: Maria A. Dos Santos (mariados)
> >> Sent: Saturday, March 11, 2006 12:02 PM
> >> To: [email-masked]; [email-masked]
> >> We googled "l2tp client" and found SixXs release note mentioned
> >> 
> >>  "L2TP Support (Yes, even under Windows one can do IPv6 in PPP in 
> >> L2TP :)"
> >> 
> >> a window client that will have l2tp capability.
> >> 
> >> Bill queried Jeroen Massar at SixXs and confirmed that the l2tp 
> >> capability will probably be available in 2 months to the public.
> >> 
> >> http://www.sixxs.net/tools/aiccu/history/
> >> 
> >> Just one example...
> >> 
> >> alice
> >> 
> >>> Sent: Friday, 10 March, 2006 9:30
> >>> To: [email-masked]
> >>> Hi David,
> >>> I think the main discussion here has been related to the lack of 
> >>> IPv6 support for L2TP in XP (and I guess is the same in W2003). 
> >>> Unless I misread the link that you provided, I think 
> doesn't mention 
> >>> IPv6 support at all.
> >>> 
> >>> I also recall having checked with Microsoft a couple of times and 
> >>> they confirmed that will be only available in Vista. Of 
> course, this 
> >>> can change, and that will be great actually !
> >>> 
> >>> Regards,
> >>> Jordi
> >>> 
> >>> 
> >>> 
> >>> 
> >>>> Fecha: Fri, 10 Mar 2006 11:12:36 -0600
> >>>> Para: David Ward <[email-masked]>, "[email-masked]"
> >>>> <[email-masked]>, "Durand, Alain"
> >>> <[email-masked]>
> >>>> Asunto: Re: [Softwires] Notes and Consensus from Interim
> >> Meeting in
> >>>> Hong Kong
> >>>> 
> >>>> Although I am sitting back allowing folks to discuss
> >>> various issues, I
> >>>> had to step in w/ the results of a 5 min google search as
> >>> there hasn't
> >>>> been much information presented on the list wrt what is actually 
> >>>> available vs
> >>>> conjecture:
> >>>> 
> >>>> 
> >>>>> From Microsoft on L2TP clients:
> >>>> 
> >>>> Explains how to get L2TP on XP and earlier versions of
> >>> windows (yes, I
> >>>> wrote "XP").
> >>>> 
> >>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;818043
> >>>> 
> >>>> Alice has already sent out how to turn off IPsec.
> >>>> 
> >>>> 
> >>>> Clients for POSIX OS:
> >>>> 
> >>>> http://sourceforge.net/projects/rp-l2tp/
> >>>> 
> >>>> 
> >>>> A quick google gave this information on L2TP as well:
> >>>> 
> >>>> 0) Cisco support since 2000
> >>>> 
> >>>> 1) Juniper:
> >>>> 
> >>>> http://www.juniper.net/products/junose/105016.html
> >>>> 
> >>>> The ERX now supports IPv6 for BRAS (PPP & L2TP)
> >>>> 
> >>>> (Since at least September 2003)
> >>>> 
> >>>> 2) Laurel (now ECI):
> >>>> 
> >>>> 
> >>> 
> >> 
> http://www.convergedigest.com/PacketSystems/packetsysarticle.asp?ID=1
> >> 1
> >>>> 350
> >>>> 
> >>>> Laurel is also releasing new system software that adds non-stop 
> >>>> sessions,
> >>>> IPv6  and LAC (L2TP Access Concentrator) functionality.
> >>>> http://www.laurelnetworks.com
> >>>> 
> >>>> Since at least 07-Jun-04
> >>>> 
> >>>> 3) Nortel:
> >>>> 
> >>>> 
> >>> 
> >> 
> http://www.nortelnetworks.com/products/library/collateral/66014.25-10
> >> -
> >>>> 01.pdf
> >>>> 
> >>>> "Nortel Networks GGSN acts as an L2TP Access Concentrator (LAC).
> >>>> Address allocation, L2TP Network Server (LNS) and ipv6
> >> routing can
> >>>> take place within those corporate administrative domains.
> >>>> 
> >>>> (Posted October 2001)
> >>>> 
> >>>> It appears that both client and servers are available for
> >>> desired OS
> >>>> and interoperability from various commercial vendors.
> >>>> 
> >>>> -DWard
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>> 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

---

From: "Fiumano, Michael F [NTK]" <[email-masked]>
Date: Wed, 15 Mar 2006 13:44:57 -0600

Thanks for the response.

I suppose it all depends on what kind of service provider you are and how you measure your 80%.

I think that Router to Router is as equally important to service providers who do not service end users as Windows to Tunnel Device is to service providers who do serve end users directly.

Granted that there are a lot more end users than anything else which I suppose gets you that 80%, but if there is no mechanism for Tier 1 Internet providers to better serve those Tier 2/3 providers who service the last mile and end users, then there is another problem as well. 

In the end, Router to Router is as equally important to serving those end users.

Michael Fiumano
Senior Network Engineer
IP Core Infrastructure
703-689-5875 Wk
703-598-2434 Cel

-----Original Message-----
From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2006 2:27 PM
To: [email-masked]
Subject: Re: [Softwires] Notes and Consensus from Interim Meeting in Hong Kong

Hi Michael,

We aren't denying the need for support in others, but we like it or not, XP
is 80-85% of the market, and is an important target for what the WG is
trying to achieve.

How much important is that vs. Router to Router, is why I asked the point 3)
to weight it.

Anyway my understanding is that in a carrier network most probably you will
not be using softwires, unless you're needing just a default route, as it
may be the case if you manage the CPE router.

Regards,
Jordi

> De: "Fiumano, Michael F [NTK]" <[email-masked]>
> Fecha: Wed, 15 Mar 2006 13:06:29 -0600
> Para: <[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
> 
> Hello,
> 
> Why do all solutions "require" Windows at all???  I have the need to use this
> standard to enable a port on my network to tunnel v6 over my v4 infrastructure
> to a v6 enabled part of my network.  I hope that this is being kept in
> consideration for the solution space.
> 
> As an operator of a large network, the problems I see aren't always from a end
> host.  I would prefer an L2TPv3 solution preferably as we use this technology
> today as a L2 psuedowire transport across our network.
> 
> Maybe I am off base, and this is not being given any attention because it is
> assumed that this will work, but please consider this when talking to your
> solutions as well.
> 
> Thanks,
> Michael Fiumano
> Senior Network Engineer
> IP Core Infrastructure
> 703-689-5875 Wk
> 703-598-2434 Cel
>> De: "Bill Storer (bstorer)" <[email-masked]>
>> Responder a: <[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
>> 
>> To summarize here:
>> 
>> 1. None of the proposed solutions are supported by standard issue "out of the
>> box" Microsoft Windows.  All of the solutions will require loading extra
>> software on Windows.
> 
> I'm not sure if this was a requirement, not in my opinion. It will be ideal,
> but we know is difficult for old OSs.
> 
>> 2. L2TP is closest in the above sense as it is supported by standard Windows
>> XP for IPv4/IPv4 tunneling.
> 
> With a small trick to disable IPsec, but I guess it could be automated.
> 
> It will be by SixXS, but agree, within a good timing in my opinion (actually
> shorter timing that I will say is the required one, but that's a different
> discussion).
> 
>> 5. Most importantly, L2TP is widely supported by the major concentrator
>> vendors.
> 
> Now, if you compare L2TP with TSP (I'm not advocating for one or the other,
> just trying to analyze the situation), TSP seems better to integrate from
> the client perspective and no need to play tricks in any OS. However has
> less support from the server side.
> 
> 1) Technical detailed comparison of different aspects among both of them,
> pros and cons (i.e., overhead, prefix delegation, DNS, etc.).
> 
> 2) How much time it will take for router/concentrator vendors to implement
> TSP, and if it will happen in case we choose it.
> 
> 3) How much weight we give to the support in routers vs. the support in
> clients.
> 
> Not easy ...
> 
>> 
>> Bill
>> 
>>>  "L2TP Support (Yes, even under Windows one can do IPv6 in
>>> PPP in L2TP :)"
>>> 
>>> Bill queried Jeroen Massar at SixXs and confirmed that the
>>> l2tp capability
>>> will probably be available in 2 months to the public.
>>> 
>>>> I think the main discussion here has been related to the lack
>>>> of IPv6 support for L2TP in XP (and I guess is the same in
>>>> W2003). Unless I misread the link that you provided, I think
>>>> doesn't mention IPv6 support at all.
>>>> 
>>>> I also recall having checked with Microsoft a couple of times
>>>> and they confirmed that will be only available in Vista. Of
>>>> course, this can change, and that will be great actually !
>>>> 
>>>> Regards,
>>>> Jordi
>>>> 
>>>> 
>>>> 
>>>> 
>>> http://www.convergedigest.com/PacketSystems/packetsysarticle.asp?ID=11
>>>>> 350
>>>>> 
>>> http://www.nortelnetworks.com/products/library/collateral/66014.25-10-
>>>>> 01.pdf
>>>>> 
> 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.
> 
> 
> 
> 

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: "Fiumano, Michael F [NTK]" <[email-masked]>
Date: Wed, 15 Mar 2006 13:49:58 -0600

Actually, the CE devices do not terminate the pseudowires.  We terminate them on our Edge routers going to the customer.  L2 in on one end of the network, L2 out on the other. 

I would like to see the Edge routers take v4/v6 dualstack, split off v6 and pseudowire it to another router in the network which is connected to the v6 capable parts of the network.

This would allow us to offer a "native" v4/v6 service and allow us to get around problem routers in the network where deploying v6 is not an option.

Michael Fiumano
Senior Network Engineer
IP Core Infrastructure
703-689-5875 Wk
703-598-2434 Cel

-----Original Message-----
From: JF Tremblay [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2006 2:38 PM
To: Fiumano, Michael F [NTK]; [email-masked]
Subject: RE: [Softwires] Notes and Consensus from Interim Meeting in Hong Kong

> Hello,

Hi Michael.
Thanks for your input. Some comments/questions below.

> Why do all solutions "require" Windows at all???  I have the need to
> use this standard to enable a port on my network to tunnel v6 over my
> v4 infrastructure to a v6 enabled part of my network.  I hope that
> this is being kept in consideration for the solution space.

According to the problem statement, we have to consider host-based 
solutions for the hub & spokes problem (scenario #2 and #3). Windows XP 
constitutes a large part of the current dual-stack capable host base.

> As an operator of a large network, the problems I see aren't always
> from a end host.  I would prefer an L2TPv3 solution preferably as we
> use this technology today as a L2 psuedowire transport across our
> network.

Right, a CPE can terminate the softwire (scenario #1). I'm curious 
about something though. In your current L2 pseudowire deployment, is 
any of the pseudowires terminated directly on a CPE device (enterprise 
or end user)? How easily can these be upgraded to IPv6 and L2TPv3 for 
softwire termination purposes?

Thanks,
Jean-Francois Tremblay
Hexago
-------------------------------------------------
http://www.freenet6.net : Free IPv6 Connectivity
-------------------------------------------------

> Maybe I am off base, and this is not being given any attention
> because it is assumed that this will work, but please consider this
> when talking to your solutions as well.
>
> Thanks,
> Michael Fiumano
> Senior Network Engineer
> IP Core Infrastructure
> 703-689-5875 Wk
> 703-598-2434 Cel
>> Conversación: [Softwires] Notes and Consensus from Interim Meeting
>> in Hong Kong
>> 1. None of the proposed solutions are supported by standard issue
>> "out of the box" Microsoft Windows.  All of the solutions will
>> require loading extra software on Windows.
>
> I'm not sure if this was a requirement, not in my opinion. It will be
> ideal, but we know is difficult for old OSs.
>
>> 2. L2TP is closest in the above sense as it is supported by standard
> It will be by SixXS, but agree, within a good timing in my opinion
> (actually shorter timing that I will say is the required one, but
> that's a different discussion).
>
> Now, if you compare L2TP with TSP (I'm not advocating for one or the
> other, just trying to analyze the situation), TSP seems better to
> integrate from the client perspective and no need to play tricks in
> any OS. However has less support from the server side.
>
> 1) Technical detailed comparison of different aspects among both of
> them, pros and cons (i.e., overhead, prefix delegation, DNS, etc.).
>
> 2) How much time it will take for router/concentrator vendors to
> implement TSP, and if it will happen in case we choose it.
>
> 3) How much weight we give to the support in routers vs. the support
> in clients.
>
> Not easy ...
>
>>
>> Bill
>>
> 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
> contents of this information, including attached files, is prohibited.
>
>
>
>

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Wed, 15 Mar 2006 12:28:03 -0800

Michael,

sorry to jump in like this, just trying to understand this better.
What you describe sounds more like the "Mesh" problem in which
the softwires are setup within the ISP/core network, not from
home network to ISP.  Is that right?

alice

> Sent: Wednesday, 15 March, 2006 11:50
> To: JF Tremblay; [email-masked]
> Actually, the CE devices do not terminate the pseudowires.  
> We terminate them on our Edge routers going to the customer.  
> L2 in on one end of the network, L2 out on the other. 
> 
> I would like to see the Edge routers take v4/v6 dualstack, 
> split off v6 and pseudowire it to another router in the 
> network which is connected to the v6 capable parts of the network.
> 
> This would allow us to offer a "native" v4/v6 service and 
> allow us to get around problem routers in the network where 
> deploying v6 is not an option.
> 
> Michael Fiumano
> Senior Network Engineer
> IP Core Infrastructure
> 703-689-5875 Wk
> 703-598-2434 Cel
> According to the problem statement, we have to consider 
> host-based solutions for the hub & spokes problem (scenario 
> #2 and #3). Windows XP constitutes a large part of the 
> current dual-stack capable host base.
> 
> Right, a CPE can terminate the softwire (scenario #1). I'm 
> curious about something though. In your current L2 pseudowire 
> deployment, is any of the pseudowires terminated directly on 
> a CPE device (enterprise or end user)? How easily can these 
> be upgraded to IPv6 and L2TPv3 for softwire termination purposes?
> 
> Thanks,
> Jean-Francois Tremblay
> Hexago
> attention because 
> > it is assumed that this will work, but please consider this when 
> > talking to your solutions as well.
> >
> > Thanks,
> > Michael Fiumano
> > Senior Network Engineer
> > IP Core Infrastructure
> > 703-689-5875 Wk
> > 703-598-2434 Cel
> >>>> Subject: Re: [Softwires] Notes and Consensus from 
> Interim Meeting 
> >>>> in Hong Kong
> >>>>
> >>>> Hi David,
> >>>>
> >>>> Unless I misread the link that you provided, I think doesn't 
> >>>> mention IPv6 support at all.
> >>>>
> >>>> they confirmed that will be only available in Vista. Of course, 
> >>>> this can change, and that will be great actually !
> >>>>
> >>>> Regards,
> >>>> Jordi
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 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,

---

From: "Fiumano, Michael F [NTK]" <[email-masked]>
Date: Wed, 15 Mar 2006 15:28:37 -0600

Great, that being the case though, it may make more sense to use L2TPv3 for the MESH case right off the bat instead of going down the L2TPv2 path which seems to only be required due to the end user workstation requirements.

Michael Fiumano
Senior Network Engineer
IP Core Infrastructure
703-689-5875 Wk
703-598-2434 Cel

-----Original Message-----
From: Durand, Alain [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2006 4:18 PM
To: Fiumano, Michael F [NTK]; Maria A. Dos Santos (mariados); JF Tremblay; [email-masked]
Subject: RE: [Softwires] Notes and Consensus from Interim Meeting in Hong Kong

What you are describing fits into the mesh case.

   - Alain. 

> Sent: Wednesday, March 15, 2006 4:15 PM
> To: Maria A. Dos Santos (mariados); JF Tremblay; [email-masked]
> What I was describing was definitely NOT from home network to 
> ISP.  I'm not 100% sure if what I was describing "fits" the 
> "Mesh" scenario or not.
> 
> Michael Fiumano
> Senior Network Engineer
> IP Core Infrastructure
> 703-689-5875 Wk
> 703-598-2434 Cel
> From: Maria A. Dos Santos (mariados) [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2006 3:28 PM
> To: Fiumano, Michael F [NTK]; JF Tremblay; [email-masked]
> What you describe sounds more like the "Mesh" problem in 
> which the softwires are setup within the ISP/core network, 
> not from home network to ISP.  Is that right?
> 
> alice
>  
> 
> split off 
> > v6 and pseudowire it to another router in the network which is 
> > connected to the v6 capable parts of the network.
> > 
> allow us to 
> > get around problem routers in the network where deploying 
> v6 is not an 
> > option.
> > 
> > Michael Fiumano
> > Senior Network Engineer
> > IP Core Infrastructure
> > 703-689-5875 Wk
> > 703-598-2434 Cel
> > solutions for the hub & spokes problem (scenario
> > #2 and #3). Windows XP constitutes a large part of the current 
> > dual-stack capable host base.
> > 
> > >>>>> De: David Ward <[email-masked]> Responder a: 
> > >>>>> <[email-masked]>
> > >>>> Barcelona 2005 Global IPv6 Summit Slides available at:
> > >>>> http://www.ipv6-es.com
> > >>>>

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 15 Mar 2006 16:50:12 -0500

In the mesh case you can have the encaps of your choice negotiated via BGP extensions. This is orthogonal to the current discussion of L2TPv2 in the hub and spoke case

    - Alain.

-----Original Message-----
From: Fiumano, Michael F [NTK] <[email-masked]>
To: Durand, Alain; Maria A. Dos Santos (mariados) <[email-masked]>; JF Tremblay <[email-masked]>; [email-masked] <[email-masked]>
Sent: Wed Mar 15 16:28:37 2006
Subject: RE: [Softwires] Notes and Consensus from Interim Meeting in Hong Kong

Michael Fiumano
Senior Network Engineer
IP Core Infrastructure
703-689-5875 Wk
703-598-2434 Cel

-----Original Message-----
From: Durand, Alain [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2006 4:18 PM
To: Fiumano, Michael F [NTK]; Maria A. Dos Santos (mariados); JF Tremblay; [email-masked]
Subject: RE: [Softwires] Notes and Consensus from Interim Meeting in Hong Kong

   - Alain.

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Wed, 15 Mar 2006 21:15:04 -0800

> Sent: Wednesday, 15 March, 2006 16:14
> To: Bill Storer (bstorer); [email-masked]
> --On Wednesday, March 15, 2006 2:32 PM -0800 "Bill Storer (bstorer)" 
> <[email-masked]> wrote:
> > Hi JF,
> 
> Hi Bill.
> 
> > You mention that we need to consider the number of vendors 
> supporting 
> > L2TP in a Softwires context.  Large numbers of L2TP Softwires users 
> > would certainly bolster the L2TP position.  However, those 
> numbers are 
> > not necessary to demonstrate support, scalability, and 
> manageability 
> > of L2TP for the Softwires service provider. The reason for this is 
> > that L2TP is just transporting PPP packets for Softwires.
> > This is business as usual for an existing implementation of L2TP.
> 
> Agreed for scalability and manageability, but for support, I 
> have some reserves. Honestly, I'm not a L2TP expert, but 
> let's say for a second I am an implementer with an existing 
> L2TP platform (server). If I plan to support softwires 
> scenarios, I would expect that some work has to be done and 
> it won't come for free.
> 
> For example, I would ask myself what has to be changed to 
> support L2TP over IPv6 transport for a DSTM-like (v4 in v6) 
> scenario. I would very likely need changes to my L2TP 
> implementation to support v6 transport, add an IPCPv4 
> implementation if I don't have one, and a DHCPv4 server as 
> well. For IPv6 in IPv4, I would also need an IPCPv6 client 
> and server, a DHCPv6 server, etc. Yes, these things do exist 
> now, but I need to integrate them to my product and this 
> takes some time.

ok, let's break it down.

If you are a ISP with l2tp, most likely, you are running
IPv4 over l2tp over IPv4 (that's what ISPs use in today's
L2TP VPN deployments), so we will have the following upgrade
scenerios for softwires:

1) from ipv4 over l2tpv2 over ipv4 ---> to ipv4 over l2tpv2 over (IPv6)

On ISP side:
IPv4CP must be running already.
DHCP, very likely already running (correct me if this is definitely wrong)
The only thing missing is the IPv6 transport support.  yes, the
l2tpv2 implementation will need upgrade.  But the basic protocol
is not changed at all, only adding a new transport support.  The ISP
will know that all the reliability/managability/scalablity will
still be there after the upgrade.  So this effort, even it takes some
time to implement, is much smaller and safer than switching totally to 
a new protocol.  This will be more important if the same LNS is being
used to terminate VPN tunnels and softwires, it will be much easier
for ISP to manage one single protocol (accounting and MIB) than two.

On client side:
For example, XP now has PPPv4 over l2tpv2 over IPv4 support (with option
to turn off IPsec).  DHCP client is also supported.  So again, we need
to add IPv6 transport support to l2tp.  I am not sure how big this effort
will be (know nothing about windows programming), but SixXs implemented 
the l2tp functionality in only days (which is not released yet but 
implemented and working) and adding IPv6 transport should be small 
if we use SixXs's l2tp implementation as reference point.

2) from ipv4 over l2tpv2 over ipv4 ---> to (IPv6) over l2tpv2 over ipv4

On ISP side:
Since l2tpv2 over ipv4 is already in place, all ISPs worry about are
IPv6CP and DHCPv6.  As you said, these are available standard components 
and should be able to plug in and integrate, yeah, it will take some time.
But I would think that DHCPv6 is the right way to go anyway rather than 
adding redundant configuration capability into the softwire protocol
(for now we may just need prefix PD and DNS, but there will be more
options we need in the future).  So as we see, today's large-scale
deployed l2tpv2 over ipv4 stays put which will give ISPs 
strong confidence when adding softwires onto the LNSes.

On the client side:
It's the same as discussed, the major concern is windows client.
There are/will be free downloadable ipv6 over l2tpv2 over ipv4
client available (i.e. SixXs in two months or so).  And adding
DHCPv6 client on windows, same argument as DHCPv6 should be the
way to go for configuration anyway.

Well, this is just what I think with my limited knowledge on
the topic.  Ultimately, we may need to hear from the ISPs to
see what is realistic.  Or if both ipv4-over-ipv6 and ipv6-over-ipv4
are crucial in the next few months, or can we push ipv4-over-ipv6
to a bit further timeline.  That will certainly makes a difference
to the TTM criteria?

cheers =)
alice

> 
> My point, in brief, is that future vendor support and the 
> possibility of a short-term end-user deployment cannot be 
> demonstrated using the existing L2TP install base.
> 
> JF
> 
> >
> >> Sent: Wednesday, March 15, 2006 10:18 AM
> >> To: Bill Storer (bstorer); Maria A. Dos Santos (mariados); 
> >> [email-masked]; [email-masked]
> >> --On Wednesday, March 15, 2006 8:54 AM -0800 "Bill Storer 
> (bstorer)"
> >> <[email-masked]> wrote:
> >>
> >> > To summarize here:
> >>
> >> Bill,
> >> Let me add on this.
> >>
> >> Right. However, we should differentiate between a simple 
> application 
> >> (like a TSP client) and something that requires 
> integration with the 
> >> OS such as a new network driver. The level of complexity 
> involved is 
> >> different.
> >>
> >> TSP uses existing host resources, that makes a huge difference for 
> >> the time-to-market requirement.
> >>
> >> > 2. L2TP is closest in
> >> > the above sense as it is supported by standard Windows XP for
> >> > IPv4/IPv4 tunneling.
> >>
> >> TSP also uses standard tunneling in Windows XP for IPv6 in IPv4. 
> >> (btw, did you mean IPv6/IPv4 in the above statement?)
> >>
> >> Idem for TSP. There are also plan to license the client 
> under a BSD 
> >> license.
> >>
> >> L2TP is not yet implemented by the SixXS client, from what I 
> >> understand. TSP has been implemented on a wide range of OS 
> and by CPE  
> >> manufacturers such as NEC, Draytek and Panasonic. It is also 
> >> implemented on the SixXS client.
> >>
> >> Most importantly, how many vendors actually support L2TP 
> within the 
> >> softwires context? How many vendors offer L2TP for IPv6 
> access? How 
> >> many can support tunneling IPv4 over a native IPv6 network?
> >>
> >> The current deployment of L2TP is indeed a factor to 
> consider. But we  
> >> have to consider deployment within the softwires context. 
> The current  
> >> deployment of L2TP specific to IPv6 transition is small.
> >>
> >> And I'd like to add:
> >> 6. TSP is used and deployed now by several ISPs, reserach networks 
> >> and US DoD agencies for IPv6 access. How many end 
> customers actually 
> >> use L2TP for IPv6 access now?
> >>
> >> Based on the above information, it's clear that L2TP and 
> TSP are both  
> >> very close to the solution we are looking for, with TSP having an 
> >> edge in actual deployment for IPv6 transition.
> >>
> >> IMHO, the question naturally stemming from this is could 
> we possible 
> >> consider two protocols to be standardized for softwires? 
> If we don't,  
> >> then we should debate modifying the existing criteria list 
> (possibly 
> >> to include a clear reference to time-to-market) and then 
> debate the 
> >> merits of each protocols in details (i.e. not with wild guesses).
> >>
> >> JF
> >>
> >> >
> >> > Bill
> >> >
> >> >> Subject: RE: [Softwires] Notes and Consensus from 
> Interim Meeting 
> >> >> in Hong Kong
> >> >>
> >> >> Jordi,
> >> >>
> >> >> > > Laurel is also releasing new system software that adds 
> >> >> > > non-stop sessions,
> >> >> > for the use of the individual(s) named above. If you 
> are not the