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

From: "Durand, Alain" <[email-masked]>
Date: Sun, 19 Mar 2006 16:53:11 -0500

Laurent,

The charter of softwires is not to deprecate anything.
It is to pick one solution that fit the most our problem statement,
and eventually explain any kind of necessary customization.

With regard to TSP status at IETF, it is already submited to the RFC
editor
as individual submission, so it will have its own existence in the
standard
world regardless of what softwires does or does not.

Now, wrt TTM, I would hate to see the wg turning into a
cisco/juniper/inser-your-favorite-vendor
user group the same way it has last weeks turned dangerously into a
microsoft user group.

Let's try to finish the technical aspects of the discussion.

   - Alain.

> -----Original Message-----
> From: Laurent Toutain [mailto:[email-masked]] 
> Sent: Sunday, March 19, 2006 1:40 PM
> To: Maria A. Dos Santos (mariados)
> Cc: [email-masked]
> Subject: Re: [Softwires] Technical Comparison between L2TPv2 and TSP
> 
> 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.

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

---

From: "Durand, Alain" <[email-masked]>
Date: Mon, 20 Mar 2006 00:30:59 -0500

Jordi,

I think you have a wrong picture of mesh. A service provider could very well use Mesh in its core and hub&spoke to connect leaf customers, all that using the same PE routers.

   - Alain.

-----Original Message-----
From: JORDI PALET MARTINEZ <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Mon Mar 20 00:07:42 2006
Subject: Re: [Softwires] Technical Comparison between L2TPv2 and TSP

> De: "Maria A. Dos Santos (mariados)" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Sun, 19 Mar 2006 20:40:06 -0800
> Para: <[email-masked]>, <[email-masked]>
> Conversación: [Softwires] Technical Comparison between L2TPv2 and TSP
> Asunto: RE: [Softwires] Technical Comparison between L2TPv2 and TSP
> 
> Jordi, 
> 
> I am going to ask a simple question... why? =)

My view of the problem is that an ISP is typically not having both problems
(name it scenarios if you prefer). Either they have customers that need a
single exit path (a static route), or multiple (full routing). Even if we
consider the case where an ISP has both type of customers, typically they
will be hanging from separate links terminated in different boxes.

Of course, I understand that from the point of view of a router
manufacturer, is easy to implement a single protocol, specially if it is
almost done ;-), and this is a good thing from the TTM perspective, but is a
different point that what you indicated below, I thing.

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

**********************************************
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: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Mon, 20 Mar 2006 15:47:02 -0800

JF, thanx for the clarification.

alice

> From: JF Tremblay [mailto:[email-masked]] 
> Sent: Monday, 20 March, 2006 5:57
> To: Maria A. Dos Santos (mariados); [email-masked]
> Subject: RE: [Softwires] Technical Comparison between L2TPv2 and TSP
> 
> --On Sunday, March 19, 2006 4:02 PM -0800 "Maria A. Dos 
> Santos (mariados)" <[email-masked]> wrote:
> 
> >
> >
> >> From: JF Tremblay [mailto:[email-masked]]
> >> Sent: Sunday, 19 March, 2006 15:02
> >> To: Maria A. Dos Santos (mariados); [email-masked]
> >> Subject: RE: [Softwires] Technical Comparison between 
> L2TPv2 and TSP
> >>
> >> --On Saturday, March 18, 2006 7:17 PM -0800 "Maria A. Dos Santos 
> >> (mariados)" <[email-masked]> wrote:
> >>
> >> > JF, thanx for the response and updates on the TSP.
> >> >
> >> > Please see responses inline.
> >>
> >> I only have one comment to add, so I'll skip the rest.
> >>
> >> >
> >> >> From: JF Tremblay [mailto:[email-masked]]
> >> >> Sent: Saturday, 18 March, 2006 18:24
> >> >> To: Maria A. Dos Santos (mariados); [email-masked]
> >> >> >         - 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?
> >>
> >> 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.
> >
> > ok, got it.  From the client's point of view, tunnel broker 
> speaks for 
> > the tunnel server.  ok, I will mark this point out-of-scope of 
> > softwires.
> >
> > There is another point I would like to clarify.  In the TSP 
> draft, it 
> > states that after the tunnel establishment, the same UDP 
> port will be 
> > used for IP traffic and keepalive (so the same NAT entry will be 
> > used).
> >
> > So does this means no more TSP control messages can be exchanged 
> > between the TSP client and the server after the tunnel is 
> established?  
> > But I  remember we talked about the TSP server can request 
> the client 
> > to reduce
> >
> > the keepalive frequency if the link is too congested.  In 
> general, is 
> > TSP able to exchange/update status of the tunnel after the tunnel 
> > establishment phase?  Can you explain a bit?
> 
> The keepalive frequency is negotiated before the 
> establishment of the tunnel and can't be changed afterward 
> without renegotiating. According to the draft, the client 
> chooses a value (makes sense, the client knows its own NAT) 
> and sends it to the server. The frequency is returned to the 
> client along with the tunnel information. The client must use 
> the value returned by the server. The frequency returned will 
> be the same than the original one if the value is acceptable 
> to the server, otherwise it would be adjusted.
> 
> JF
>

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Mon, 20 Mar 2006 15:56:54 -0800

> From: Marc Blanchet [mailto:[email-masked]] 
> Sent: Monday, 20 March, 2006 9:03
> Le 06-03-19 à 22:29, Maria A. Dos Santos (mariados) a écrit :
> 
> >
> >>>         - TSP embeds it's own prefix DP, meaning extra support is
> >>>           required for TSP in addition to the standards, 
> i.e. DHCP.
> >>>
> >>
> >> I consider this a good thing, because otherwise we are requiring 
> >> necessarily
> >> DHCPv6 support in all kind of devices, and it was noted 
> already that 
> >> some have no plans for supporting it.
> >>
> >> DHCPv6 can also be used anyway.
> >
> > I agree and disagree, based on my understanding, I may be wrong.
> > For devices that don't support dhcp, yes, they simply get 
> the prefix 
> > via tsp.  But for devices that prefer to use dhcp, if the 
> SC sends the 
> > prefix via the tsp, the device (SI) either has to just take it from 
> > tsp (eventhough it prefers dhcp), or somehow 
> rejects/ignores the tsp 
> > value and perform dhcp later.  Is this possible?
> 
> the TSP client optionally requests the prefix. So if the TSP 
> client does want to use DHCPv6 for prefix delegation, it just 
> has to _not_ request a prefix to the broker.
> 
> - requesting a prefix within TSP is an optional feature, not 
> mandatory feature.
> - similar to DNS stuff also handled in TSP session.
> - the advantage when using these optional features is that 
> within a single authenticated session, you get everything you 
> need for an IPv6 service.
> 
> btw, these features were requested by real users doing real 
> v6 deployment.

Thankyou for the clarification! =)

alice

> Marc.