Subject: RE: [Softwires] Technical Comparison between L2TPv2 and TSP

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Sat, 18 Mar 2006 19:17:08 -0800

JF, thanx for the response and updates on the TSP.

Please see responses inline.

Alice

> -----Original Message-----
> From: JF Tremblay [mailto:[email-masked]] 
> Sent: Saturday, 18 March, 2006 18:24
> To: Maria A. Dos Santos (mariados); [email-masked]
> Subject: Re: [Softwires] Technical Comparison between L2TPv2 and TSP
> 
> --On Friday, March 17, 2006 7:51 PM -0800 "Maria A. Dos 
> Santos (mariados)" <[email-masked]> wrote:
> 
> > All,
> >
> > We have seen a lot of discussions comparing L2TP and TSP on 
> the list, 
> > focusing on the TTM requirement.  But what is missing in the 
> > comparison is the technical aspect.  The following lists 
> out all the 
> > technical categories identified in the Softwires problem 
> statement and 
> > how L2TP and TSP satisfy them.  Hopefully, this comparison 
> will give 
> > us a better picture.
> 
> Hi Maria.
> Agreed, a good complete technical comparison was missing from 
> our previous discussions. Glad you took the time to write 
> down all of this.
> 
> > JF, please feel free to provide correct info on TSP, I did my best 
> > according to the TSP draft and your preso.
> 
> Of course. See below.
> 
> > cheers,
> > alice
> >
> > -------------------------------------------------------------------
> > 1) Standardisation Status
> >
> >         L2TP is designed specially for wire (layer 2) emulation.
> >         L2TP fits right into the Softwire paradigm in which L2TP
> >         signals the L2 attributes during control setup as well as
> >         manage the wire post initial setup.
> 
> The problem statement does not mention L2 as a base paradigm.

You are right.  Softwire is not the same as any of the hardwires/
L2-links (atm, fr, ether, etc) that L2TP emulates today, in terms of 
physical properties.  But functionality wise (serving as the lower 
layer for L3 traffic to pass through) is the same, softwire micmics
a hardwire.  That's what I mean.  

> 
> >         L2TP has been deployed widely and is well proven in this
> > role.           It provides a layered solution such that other
> > protocols like          PPP, DHCP, etc run on top of the wire just
> > like they would for          standard hardwires.
> >
> >         * L2TPv2 (RFC2661) has been standard since 1999 and protocol
> >           has been well tested and proven by large-scale VPN 
> > deployments.
> >           Complete suite of l2tp standards exists and widely
> > implemented:	
> >
> >           RFC 2661 - "Layer Two Tunneling Protocol"
> >           RFC 2867 - "RADIUS Accounting Modifications for Tunnel
> >                       Protocol Support"
> >           RFC 3371 - "Layer Two Tunneling Protocol "L2TP" Management
> >                       Information Base"
> >           RFC 3193 - "Securing L2TP using IPsec"
> >           RFC 3948 - "UDP Encapsulation of IPsec ESP Packet"
> >           RFC 3145 - "L2TP Disconnect Cause Information"
> >           RFC 3308 - "Layer Two Tunneling Protocol (L2TP) 
> > Differentiated
> >
> >                       Services Extension"
> >
> >         - TSP is a relatively new draft:
> >           draft-blanchet-v6ops-tunnelbroker-tsp-03.txt
> 
> TSP has been proposed in draft-vg-ngtrans-tsp-00.txt in 2001 
> used since then.

ok, I will update it.

> 
> >         - TSP draft only specifies protocol between the 
> tunnel client
> >           and broker, no protocol defined between the tunnel broker
> >           and tunnel server.
> 
> This is out-of-scope for softwire.

correct me, I am still trying to understand how the whole TSP
solution works.

TSP client contacts TSP server (which is tunnel broker)
TSP server negotiates with client (authen, capablity, prefix and server
ip)

after TSP server replied OK to client, from client point of view, tunnel
is up and client can start forwarding traffic over tunnel toward server.

So I assume, before TSP server replied ok to client, it has already
contacted
the tunnel server about the tunnel and makes sure that it is also
established
on the tunnel server.  Why is this part out-of-scope for softwires?  
Is this part documented somewhere?

> 
> > 2) Technology Reuse
> >
> >         * Reuse of L2TP encapsulation for the MESH case, including
> >           Accounting and MIB.
> >
> >         - TSP will be one extra protocol to manage.
> 
> However, TSP reuses existing and well known encapsulation 
> types such as protocol 41.

Let me clarify.  What I mean is if on the same router we have both
Mesh and Hub&Spoke, since l2tp will be part of Mesh already, enabling
Hub&Spoke with l2tp does not require adding another protocol.
But if we enable Hub&Spoke with TSP, then we will have to add the
TSP control protocol onto the router (yes, the protocol 41 encap
will be a reuse).

> 
> > 3) Interoperability
> >
> > 	* l2tpv2 implementations include:
> >
> >              L2TPv2 has been independently implemented by 
> major router
> >              vendors, for Linux and PoSix-bases OSs and on 
> MS Windows
> >              OSs (both natively and by third-vendors).
> >
> >              Major router vendors:
> >                 Cisco, Juniper, Redback, Nortel
> >
> >              Linux and other POSIX-based OSs (GPL):
> >                 sourceforge.net, Roaring Penguin, etc
> >
> >              Native Microsoft Windows client:
> >                 ipv4 over ipv4 client:
> >                    on all windows OSs (IPsec optional)
> >                 ipv6 over ipv4 client (with PPPv6 and DHCPv6):
> >                    available on Vista / Longhorn
> >                    (now in beta testing, to be released end of 2006)
> >
> >              Downloadable Windows XP clients: ipv6 over ipv4
> >                 NTT, SixXs (to be released in 2 months), Trumpet.
> >
> >
> >         - TSP implementations include:
> >
> >              TSP Server:
> >              Hexago
> >
> >              TSP Client:
> >              Draytek, Panasonic, NEC
> >
> >              Independant implementations:
> >              ENST, University of Southampton, SixXs
> >
> >
> > 4) Address allocation
> >
> >         * l2tpv2 solution will use IPCP (v4/v6) and DHCP 
> (v6/v4) which
> >           are standard building blocks.
> >
> >
> >         - TSP embeds it's own prefix DP, meaning extra support is
> >           required for TSP in addition to the standards, i.e. DHCP.
> 
> The idea is to compensate for the lack of implementations of 
> some IPv6 protocols such as IPCPv6 and DHCPv6. This argument 
> was indeed stronger a few years ago.
> 
> > 5) Scalability
> >
> >         * L2TPv2 is proven to be scalable to the millions 
> subscribers
> >           in multiple VPN deployments (i.e. NTT, BT, AOL).
> >
> >         * Upper Tens of thousands of concurrent L2TPv2 sessions on a
> >           single node (or "LNS")
> >
> >         * Call setup rates in the hundreds per second
> >
> >         * L2TP supports a "Try another directed" message 
> allowing LNS
> >           to provide LAC a list of alternate LNSes that it 
> can connect
> >           to.  This message is currently specified for L2TPv3 only,
> > but           has been implemented for L2TPv2 and RFC2661 can be
> > extended           to cover it.
> 
> Redirection message is built-in TSP.

yes, I added this in my updated version already.
> 
> >
> >         - Freenet6 TSP deployment has about 10 thousand tunnels on a
> >           single SC.
> >         - No numbers on KDDI, AT&T and Wanadoo trials.
> 
> KDDI deployment scales to a few thousands, this was presented by Shu 
> Yamamoto at the interim.  	

yes, I updated this in the updated version already.

> 
> >
> > 6) Authentication/Security
> > 	
> > 	  * L2TPv2 supports mutual Control Channel Authentication at
> >           beginning of establishment message exchange.
> 
> Is the authentication really mutual? This wasn't clear from 
> the discussion at the interim.

yes, L2TP supports mutual tunnel authentication, lac/lns authen
each other at the beginning.  I will make sure it is clear in the 
preso for Dallas.

> 
> >         * Inherits PPP per-user Authentication
> >
> >         * Data encapsulated in session header with tunnel/session
> >           ids, provides better security than IP-in-IP (i.e.protocol
> >           0x41) encapsulation.
> >
> >         * Runs over IPSec to provide full tunnel protection
> >           * RFC 3193 - Securing L2TP using IPsec
> >           * RFC 3948 - UDP Encapsulation of IPsec ESP Packets
> >
> >
> >         - TSP Authentication not at beginning of establishment,
> >           vulnerable in load balancing redirection scenerios.
> 
> L2TP has the same issue, to my knowledge. We discussed this 
> at the interim and agreed this is a non-issue, since the 
> redirection has to happen before authentication in any case.

I remember, it was discussed.  If the tsp client sends a "version"
message and a rogue server replies the "capabilities" message which
redirects the client to a fake broker.  This can happens before
the tsp authen phase.  

With l2tp, if a rogue lns replies to the SCCRQ with a "try again
directed", client will have to authen the reply before processing
it.

alice

> 
> >         - No security related drafts for BCP or encryption.
> >         - Uses IP-in-IP (ie. protcol 0x41) for data encapsulation,
> >           "easy to spoof"
> 
> Agreed. Using strict reverse path forwarding helps in this case.
> 
> >
> > 7) OAM
> >
> > 	* L2TPv2 supports in-band signalling:
> >           - data connectivity problem will prevent tunnel
> > establishment              in the first place.
> >           - loss of data connectivity will trigger keepalive timeout
> >             and thus allows LAC/LNS to clean up stale tunnel.
> >
> >         * L2TPv2 In-band keepalives can be enabled from both LAC/LNS
> >           and only sent if there is no data traffic.  So it 
> does not 
> > add
> >
> >           extra load to congested link.
> >
> >         * L2TPv2 has standard accounting and MIB support
> >           * RFC 2867 - RADIUS Accounting extension for tunnel
> >           * RFC 3371 - L2TP MIB
> >           * RFC 3145 - L2TP Disconnect Cause Information
> >
> >         * L2TPv2 high-availability support
> >           High-availabilty/graceful restart mechanisms have been
> > built            into the protocol for redundancy purposes:
> >              draft-ietf-l2tpext-failover-06.txt - (also applies to
> > L2TPv2)
> >               "Fail Over extensions for L2TP "failover"
> >
> >         * L2TP supports VCCV, an in-band per-session ping.  VCCV 
> > serves as
> >           a diagnostic or fault detection mechanism to test the
> >           network's forwarding plane liveliness.  VCCV 
> currently only
> >           applies to L2TPv3, but it can easily be extended to work
> > with            L2TPv2.
> >              draft-ietf-pwe3-vccv-07.txt -
> >               "Pseudo Wire Virtual Circuit Connectivity Verification
> >                (VCCV)"
> >
> >
> >         - TSP uses out-of-band signaling and tunneled 
> traffic does not 
> > follow
> >           same path.  Therefore have to signal to broker that data 
> > path is
> >           down to clean up tunnel.
> >         - TSP in-band keepalives are requested by the 
> client and sent 
> > from
> >           client to server only.  In case of congestion, 
> server has to 
> > send
> >           request message to client to reduce the frequency which 
> > again adds
> >           to the traffic load.
> >         - TSP has no standard Accounting or MIB support
> >
> >
> > 8) Available encapsulations
> >
> >         * L2TPv2 RFC 2661 supports
> >           IPv6/UDP/IPv4
> >           IPv4/UDP/IPv6
> >           IPv4/UDP/IPv4
> >           IPv6/UDP/IPv6
> >           IPvX/UDP/IPxY/IPsec - this is to emphasize 
> standard support 
> > of L2TP
> >                                 over IPSec.
> >
> >         - TSP draft supports
> >           IPv6/IPv4
> >           IPv6/UDP/IPv4
> >           IPv4/IPv6
> >           extensible to others, but not yet specified in draft.
> >
> > 9) NAT traversial
> >
> > 	  * l2tpv2 runs over UDP
> >
> >         - Same for TSP
> >
> > 10) Nomadicity
> >
> >         * l2tpv2 is well integrated with RADIUS for per-user 
> > authentication
> >           and authorization.  Roaming users may get back the same
> >           IP address (if within the same administrative 
> domain) or a 
> > different
> >           IP address if outside the domain.
> >
> >         - TSP does the same.
> >
> > 11) Multicast support
> >
> >         * Multicast protocol and data traffic pass throught l2tpv2 
> > tunnel
> >           transparently.
> >
> >         - TSP can do the same.
> >
> >
> > _______________________________________________
> > 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: "Laurent Toutain" <[email-masked]>
Date: Sun, 19 Mar 2006 19:39:33 +0100

that's a good overview. I don't think Softwires will make TSP
disappear: since it
works, it will continue to work. I think, it is a good thing to focus
on time to market
for PC but we have to look forward. Providers will not only talk with
PCs, providers will
have to talk with routers and we have also to study time to market for routers.

Laurent

--
-----------------------
Serveur web du Point6 => http://www.point6.net
Laurent Toutain
ENST Bretagne
tel +33 2 99 12 70 26 - Fax +33 2 99 12 70 30

---

From: David Ward <[email-masked]>
Date: Sun, 19 Mar 2006 13:38:05 -0600

The goal of the WG isn't to make anything disappear but, we have to have one
solution moving forward. Our goal is to find one solution for H&S that meets
the requirements and we will extend in the future phases. We cannot have two
solutions for one scenario.

The TTM issues are quite a vortex since both solutions are deployed. Also,
it would be best if we limited ourselves to what we know today about
implementation: what is already available and what is announced to become
available. 

I would like to keep the discussion on the technical merits of the solutions
if possible. If the technical discussion is complete as represented by
Alice, it is good news. I want to make sure we don't close this avenue of
discussion prematurely.

Thanks

-DWard

---

From: JF Tremblay <[email-masked]>
Date: Sun, 19 Mar 2006 18:01:35 -0500

--On Saturday, March 18, 2006 7:17 PM -0800 "Maria A. Dos Santos 

> Please see responses inline.

I only have one comment to add, so I'll skip the rest.

> TSP server negotiates with client (authen, capablity, prefix and
> server ip)
>
> after TSP server replied OK to client, from client point of view,
> tunnel is up and client can start forwarding traffic over tunnel
> toward server.
>

The tunnel broker-server interactions are not described as part of TSP 
since this is independent of what TSP achieves. Actually, there's no 
way for a TSP client host to know whether the tunnel server is the same 
physical entity than the broker.

JF

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Mar 2006 21:42:07 -0600

Just a quick comment below in-line.

Regards,
Jordi

> De: "Maria A. Dos Santos (mariados)" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Sat, 18 Mar 2006 19:17:08 -0800
> Para: JF Tremblay <[email-masked]>, <[email-masked]>
> Conversación: [Softwires] Technical Comparison between L2TPv2 and TSP
> Asunto: RE: [Softwires] Technical Comparison between L2TPv2 and TSP
> 

I don't think is a real advantage, because I don't think from a realistic
point of view, we can expect the same box acting as a mesh and as a h&s box.
Both are so different scenarios, that will not be present at the same time
(in the same box).

>>>         * Multicast protocol and data traffic pass throught l2tpv2

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