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

From: David Ward <[email-masked]>
Date: Fri, 03 Mar 2006 12:01:29 -0600

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 08 Mar 2006 09:00:59 +0100

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.

2) In most of the implementations using IPsec seems also mandatory, again
time to market, in a practical perspective, is broken.

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.

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.

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

**********************************************
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: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 08 Mar 2006 08:51:42 +0100

Hi all,

I've some comments to the minutes:

1) When we discussed the decision criteria I stated that was not convinced
the criteria is specific enough for our needs. This is very important
because after we started to work on the L2TP framework on the second day, we
realized that going into details, this solution has some drawbacks (see my
next email regarding the consensus). I also insisted on this on the 2nd day
(but there is already reflected in the minutes).

2) I also stated that the time to market is relative and should be better
defined. It could be ok 6 months or we need only 3, or can we live with one
year. The point is that going into a 3-months solution could have
disadvantages that we may pay afterwards for years. There was not any
conclusion neither discussion on this.

3) Is not ATS, but ATS6, and I guess the correct way to put in the minutes
is "Automatic Tunneling Setup for/with IPv6 (ATS6) - Jordi Palet", same as
the next presentation and doing it in an uniform way for all them.

4) "Handshake can be UDP or PPP". What I presented there is that the
signaling handshake can be encapsulated in alternative ways. The actual text
uses ICMP, but anything from UDP to PPP could be used (I mentions those just
as examples).

5) I think there is some confusion about the pre-auth. I didn't said want to
add to the problem statement. Is there already, but not so clearly
described. The point is the distinction in between nomadic users or users
that are already pre-authenticated in the ISP network by other means such as
cellular users.

6) IPv6 in IPv6 encapsulation is included *for example* to support multicast
(but not exclusively). In any case, the point is to understand that ATS6
supports any encapsulation that we want to define.

7) "Jordi reported L2TP problems in hotels ...". My comment here was not
years ago (if that means long time), but just a couple of years ago and
happened several times, both using Windows and Mac OS X later. I never said
it was an early windows client, just expressed my concern that if this
happens we miss the time to market, while TSP just works always. This is key
and need to be confirmed. I didn't have time to troubleshoot the problem
when it happened to me.

Regards,
Jordi

---

From: Ole Troan <[email-masked]>
Date: Thu, 09 Mar 2006 12:00:05 +0900

Jordi,

[...]

> there are other parameters that we are also missing here.

what makes these issues a problem that softwires should solve? i.e are
there any requirement that is specific to softwires with regards to
DNS discovery and IPv4 prefix delegation?

I have always assumed the answer is "no". that any provisioning
mechanism which have been designed for hardwires should also be made
to work on softwires.

specifically to your points.

DNS discovery: how to provide DNS parameters over an IPv6 link is
already specified in an RFC. an has multiple implementations. in the
softwire case you also have the option of using the DNS discovery
mechanism for the transport or the payload protocol. I'm afraid I
can't see which bit is missing here?

IPv4 prefix delegation: IPv4 provisioning have worked fine for decades
without prefix delegation... I can't see what makes this requirement
special to softwires. if it is needed it should be specified in the
DHC WG.

/ot

---

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

Hi Ole,

See below, in-line.

Regards,
Jordi

> De: Ole Troan <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 09 Mar 2006 12:00:05 +0900
> Para: <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Asunto: Re: [Softwires] Notes and Consensus from Interim Meeting in Hong Kong
> 
> Jordi,
> 
> [...]
> 

Yes, this disappeared, I guess by mistake, in the last draft release.

> mechanism which have been designed for hardwires should also be made

Agree, with the small difference that IPv4 and IPv6 don't have the same
features and here we need to appear similar for a good solution.

> can't see which bit is missing here?

The easy solution will be to use DHCPv6 when IPv6 is the payload. I just
don't agree with this extra piece of code being required in the clients. But
also agree that DNS is not a big issue because you have IPv4 transport for
DNS.

Not an issue on the reverse case.

> special to softwires. if it is needed it should be specified in the

Agree, I'm not saying that doing so is softwires work at all. I'm saying is
needed and should be done (in DHC WG), but we can't then say that the
time-to-market for L2TP is done.

As said, I think we need a much clear/detailed criteria before having a
coherent decision.

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Mar 2006 12:51:13 +0900

Jordi,

let me paraphrase your argument if I may.

you are arguing that the softwire WG should:
  - develop softwires specific provisioning mechanisms:
    DNS discovery, address assignment and prefix delegation

from my reading of the softwire charter and the softwire problem
statement our task is to reach consensus on a tunnel encapsulation and
setup protocol. we should not re-invent new provisioning mechanisms,
but make sure that whatever solution we end up with can support the
provisioning mechanisms which have already been developed.

requiring the softwires to find a new mechanism for DNS discovery, or
reopening the "DHCPv6 is too heavyweight" discussion, is a sure way to
ensure that this working group will not get anything done any time
soon...

chairs: please correct me if my reading of the charter/PS is wrong.

cheers,
Ole

---

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

Hi Ole,

No, is not that what I'm trying to say.

What I'm saying is that we defined time-to-market as having availability of
all the required components, not necessarily being developed by this WG.

Regards,
Jordi

> Fecha: Fri, 10 Mar 2006 12:51:13 +0900

---

From: Bruno STEVANT <[email-masked]>
Date: Fri, 10 Mar 2006 10:07:28 +0100

Hi all,

I think we should first agree on a more precise definition of "time- 
to-market".
IMHO, there's at least 3 parameters :
- Protocol specification robustness : measure how much the protocol  
matches the requirements, how many features and security issues are  
left, etc...
- Equipment integration : measure how broad is the acceptance of the  
protocol inside equipment
- Operation team readiness : measure how ready are people to deploy  
and manage the protocol

 From my point of view, here is the time-to-market evaluation for  
L2TPv2/PPPv6 against TSP. I alsa want to put here my view of time-to- 
market for IPv6 ;)

L2TPv2/PPPv6:
- Protocol specification robustness : 100%
I didn't see any work done recently on L2TPv2. IPV6CP looks OK for me.
- Equipment integration : 50%
We are missing PPPv6 for Windows.
- Operation team readiness : 100%
L2TP/PPP is nowadays well deployed and people have sufficient  
management/debug/operation knowledge

TSP:
- Protocol specification robustness : 100%
TSP looks OK
- Equipment integration : 50%
Can Cisco make an implementation of TSP in less than 6 month? As for  
L2TP, we are missing a important part.
- Operation team readiness : 0%
TSP is an entirely new protocol. Operation teams have to gain  
knowledge, develop new tools to integrate the solution inside their  
core operation network

IPv6:
- Protocol specification robustness : 100%
IPv6 is no standard, WG is closed, everything looks fine but ...
- Equipment integration : 75%
IPv6 is still missing in the whole embedded market
- Operation team readiness : 10%
Only a few people amongst sysadmin and telco operators are aware of  
IPv6. Deployment still require new tools and knowledge.

Some others parameters may be added, but I think it is important to  
consider more perspectives for "time-to-market" rather than just  
"availability" ;)
For instance, I don't think that IPv6 has a 6-month time-to-market  
frame because of deployment issues (ok that is a humane problem but  
it should be considered).
More inputs welcome ...
-- 
Bruno STEVANT - Point6

Le 10 mars 06 à 08:39, JORDI PALET MARTINEZ a écrit :

> 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 11:34:43 +0100

Hi Bruno,

This has been my point all the time ... Even in the meeting ! You've done a
very good job here to express it very clearly.

Of course, more parameters could be added and everyone will score each thing
differently, but that's part of the game.

For example, I will score L2TP only 20% because the lack of readiness in XP,
unless is clear that can be provided in less than 12 months. I will also
score TSP higher if Cisco and other router vendors can provide
implementations in less than 12 months.

Not sure to agree in your 0% for operational readiness of TSP. My
understanding is that is almost a black box and not too much need to be
done.

Finally, for me the weight into the client support is much more higher than
the server. Let me explain why. If clients (SI) are widely available (I mean
with all the required features), even if the RTT is not perfect, there will
be some free (at least during some time) services for the server side (SC).
This is the same today for 6to4 and Teredo. Is a matter of ISPs to decide if
they want to deploy or not whatever protocol we choose.

This will be in fact a differentiation factor for ISPs. If they want to
provide a good service for their customers, they will deploy it. Is not so
costly to deploy a softwires solution, whichever solution we take, so not
doing so is just an excuse. Even if done in software, I think it can be less
than 1000 USD (open source implementations) for tens of thousands of
customers.

But what really concerns me is to have as much client support as possible in
one-year time frame (maximum !).

Regards,
Jordi

> De: Bruno STEVANT <[email-masked]>
> Fecha: Fri, 10 Mar 2006 10:07:28 +0100
> Para: "[email-masked]" <[email-masked]>

---

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

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=11350

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

---

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

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]>
> Conversación: [Softwires] Notes and Consensus from Interim Meeting in Hong
> Kong