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

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Sun, 19 Mar 2006 16:02:49 -0800

> -----Original Message-----
> 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.
> 
> >
> >> -----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
> >
> >>
> >> >         - 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?

thanx,
alice

> JF

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

---

From: JF Tremblay <[email-masked]>
Date: Mon, 20 Mar 2006 08:57:26 -0500

--On Sunday, March 19, 2006 4:02 PM -0800 "Maria A. Dos Santos 
(mariados)" <[email-masked]> wrote:

>> > 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
> 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 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: David Ward <[email-masked]>
Date: Mon, 20 Mar 2006 08:56:47 -0600

Into the future, you may want to use an adaptive failure detection mechanism
so you don't have to tear down the session. Also, it isn't link congestion
that is usually the issue to avoid. It is client or server resoure
capabilities (CPU) and overwhelming one or the other.

Check out BFD....

-DWard