Subject: Re: [v6tc] Make myself clearer...

From: Florent Parent <[email-masked]>
Date: Tue, 08 Mar 2005 20:47:33 -0600

-- On Wednesday, March 09, 2005 00:30:05 +0000, Tim Chown wrote:
...
> * TSP implementations.  It seems TSP is a spec written to match the
>   original freenet6/Hexago implementation.   The spec is a little vague to
>   implement the client and server end from (though we have done so here).
>   If the spec were more precise, and there were open source
> implementations   I think we'd see more such brokers deployed.
...

Tim,

I'm planning to get the -02 version with more details. Could you provide me 
some more information as to where things can be made clearer?

Thanks
Florent

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

---

From: "BAUDOT Alain RD-CORE-CAE" <[email-masked]>
Date: Wed, 9 Mar 2005 23:25:03 +0100

Hi all,

I pretty agree with Jerome's view regarding TEP discovery, that I think is not really usefull from an ISP point of view. A roaming user will connect to his well known TEP as usual, and it is not big deal if the path is not optimum in this case. This is what TB users are experiencing for a while, and what we actually do when connecting to our enterprise network through a secured VPN.

On another hand, I support the idea of refining and polishing TSP specification to make it easy to implement. Then I think a key point is about phase out. TSP should allow design of "out of band" solutions, where phasing out should results in removing tunneling stuff only, to make transition of transition as costless as possible, and to design a temporary solution less specific as possible.

My 2 cents,
Alain. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jerome Durand
Envoyé : mercredi 9 mars 2005 13:54
À : zzx-6CDO-CHOWN Tim
Cc : [email-masked]
Objet : Re: [v6tc] Make myself clearer...

Thanks for your reply Tim,

If you say some work is needed to refine the TSP specs it's fine. This is what the group should do I think. Thanks for that input.

> * Mobile users for whom the first hop to your TB is significant (e.g. if 
>   they are at the IETF here).   Then discovering a 'nearby' TB is quite
>   useful (putting aside the issue of trust).

Now for this one I don't agree. I am not sure this falls under some real business case. The question is what do we want to achieve?
   - give IPv6 connectivity to host whatever it is?
   - have service (monitored, secured) offered from provider to customer?

 From what was presented, the group targets for now the second goal. In this case you connect to a broker you know, so I am sorry we can't let aside the issue of trust. When you roam, the network where you seats can provide you some connection information with TEP information. Like it's done today for WEP key (like here in Minneapolis). Now if you don't have a tunnel broker in the network you are visiting, then I don't think it's a good idea to find the closest one.

It's much better I think:
   - to use your ISP tunnel broker (that can be using an anycast TEP)
   - to target the IPv6 VPN scenario. This is much closer to reality I think. Here for example many people have VPNs to theiur home network, and almost all traffic goes to their home network (It could be better for network security, people rely on ACL's they trust) I think this is something much more important to consider. I don't know at all if there is some v6ops work on it, sorry about it.

Jerome