Subject: [v6tc] Make myself clearer...

From: Jerome Durand <[email-masked]>
Date: Tue, 08 Mar 2005 14:14:59 +0100

Hi,

 From the goals explained at the beginning of the session, that:
   * we only cover the ISP willing to give IPv6 connectivity to its
customers
   * It's a temporary solution
   * we want to address various types of host (behind NAT...)

Then TSP fullfils these requirements, already exists and can be
deployed. Now when I said I didn't care for having it as an RFC, I just
mean that maybe it is manufacturer's business to ask for a review of the
protocol if they want to implement it as well. I'd like to have the
solution implemented by as many manufacturers as possible of course to
be capable to choose among them, but cannot do much more... But it's not
the ISP job to design the protocol (we gave the requirements).

So having TC discussing TSP is fine, and making it an RFC is also fine.

Now about the other problem that was discussed about TEP discovery (that
is orthogonal as it was presented). I think it does not fit with the
goals explained at the beginning: ISP that gives connectivity to its
customers. In this precise case we don't need any TEP discovery as the
ISP can give its customers the TEP to use very easily (could be on the
configuration CD, retrieved from a web page... and can match an anycast
address in the ISP network for example) So TEP discovery is not a
problem for an ISP setting up IPv6 tunnels to its customers.

Thanks

Jerome

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

---

From: Tim Chown <[email-masked]>
Date: Wed, 9 Mar 2005 00:30:05 +0000

Hi Jerome,

I understand completely your view, and it is likly that we will deploy a
similar service for UKERNA as you have done for Renater.

The original focus of what led to v6tc was more on the TEP discovery than 
the tunnel configuration.

I think beyond the TSP solution you need to consider:

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

* Scalability; if you need to support 100,000 users, how do those users'
  TB clients pick a TB server?  Or is there some anycast, or load balancer?

* 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.  As it is, sites/ISPs are
  reluctant to pay Hexago 20-50k$ for a TB box, and so each writes its own, 
  which turns out to be simple and not very feature-rich, and so the status
  quo of few (useful) deployed brokers continues.

Now, if you can afford the Hexago broker, and you aren't worried about
scalability (i.e. you expect a few hundred users maybe), and you're happy
for them to use your TB wherever on the globe they are...

Tim

-- 
Tim

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 09 Mar 2005 09:17:06 +0100

>  TB clients pick a TB server?  Or is there some anycast, or load balancer?

These two points are for discovery. Having an anycast prefix is already
enough. One could of course simply request a IPv4 /24 PI block from RIPE
and announce that at certain points in the Internet thus making
available their TSP or TIC or whatever configuration services. The
backends should take care of the rest, eg the syncing of user accounts
etc, but that is implementation, not protocol. The protocols work fine,
there simply is no discovery method for neither of them yet.

Which is AFAIK what this WG/BOF is supposed to be doing.

Rest of this email is political/non-technical stuff...

>  implement the client and server end from (though we have done so here).

The client is open source, the server is afaik not. Thus you only need
to write up something which spits XML from a database. If you are not
prepared to invest time and thus money in that, then just buy the box
and for once pay the people who implemented it. The world is not free
everywhere, some people actually like some food on the plate after
having worked. Apparently you mention you have implemented one, but why
is it not open sourced then if that is what you expect others to do?

>  I think we'd see more such brokers deployed.

You mean that you would see a lot of very small sites running Tunnel
Brokers, providing bad quality to users and even more likely causing a
lot of abuse on the internet. There is choice in this world you know. If
an ISP wants to do a IPv6 TB they can come to SixXS and we will set it
up with them, for free(tm). The line before mentions why we don't want
to opensource it as I don't want IPv6 to get a bad name because of bad
quality and a lot of abuse.

Also for quite a lot of years there has been:
http://carmen.ipv6.tilab.com/ipv6/tools/ipv6tb/

Not so convenient maybe, but hey, you get what you pay for. Of course it
is also quite aged by now.

>for them to use your TB wherever on the globe they are...

Who says that those boxes can only do 'a few hundred users'? If you
really want to deploy a 100k+ user network and have a lot of
requirements you will end up with a custom setup anyway, however you do
it, unless they of course support that, I don't know, might quite well
be so :) Thus why not write it up yourself then? And otherwise I am
quite sure they really would like to help you out solving that issue.

Funny btw that you want to deploy something for '100k users', who most
likely pay you for it, but don't want to invest a little bit of money
into doing it and because of those nice Open Source hypes think they can
get everything for free...

Greets,
 Jeroen

PS: The reason we didn't use TSP for SixXS is because it does not allow
for multiple tunnels per user, though you can hack around that using a
trick in the username, nor are there currently defined ayiya and
proto-41-heartbeat templates, though those can be invented of course.
The spec was clear enough and we have a TSP server but we turned that
off in favor of TIC which does comply with the requirements we have.

---

From: Tim Chown <[email-masked]>
Date: Wed, 9 Mar 2005 14:29:40 +0000

> Which is AFAIK what this WG/BOF is supposed to be doing.

I agree, hence the question.  I think the TEP discovery should cater for
such a scenario.
 
> is it not open sourced then if that is what you expect others to do?

We hope it will be sourceforged around June/July.  We did ask you to use
your code but you refused it even for academic use.  So like everyone else 
we end up rolling our own :)   We will certainly give feedback to Florent 
on what we perceived as 'loose' bits of the TSP spec.
 
> quality and a lot of abuse.

Not necessarily, but that is your choice of course.   The Hexago product 
appears fine (Jerome is one of the ISPs using it in production) but were
there a good open source TB platform we'd probably see more brokers 
deployed.  I don't share your scepticism that they'd be deployed so badly.
 
> is also quite aged by now.

Indeed, it lacks features we wanted.  But at the time is was great, and it
still works today, if you're happy with the features it has.
 
> quite sure they really would like to help you out solving that issue.

I am sure they would, which is my original point.  
 
> get everything for free...

We would want to deploy for a few hundred, maybe a few thousand, none of
whom would pay for it.   Your 'religion' is what gets you into so many heated
debates here, but I'm not rising to that ;)

-- 
Tim

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 09 Mar 2005 16:21:23 +0100

>your code but you refused it even for academic use.

You asked 'Is your tunnel broker implemenation freely available?' to
which you got an extensive response in short telling that it is
available for free but not for redistribution etc. As currently 3 (and
soon 4) NREN's are using it, your claim that it is not available for use
for academic purposes is simply false.

>So like everyone else we end up rolling our own :)

Which is everybody's free choice of course. That you don't seem to like
the fact the way we do things is your problem, not ours, but don't try
to say odd things in between lines.

>We will certainly give feedback to Florent on what we perceived as 'loose' bits of the TSP spec.
> 

You apparently did not have to handle the abuse that comes forth from
it. But you will notice soon enough.

>I am sure they would, which is my original point.  

Your point was that one should not use it when one is worried about
scalability and if you would want to limit people from using it etc.
 
>debates here, but I'm not rising to that ;)

Which 'religion'?, could you elaborate, or maybe in your perfect english
words without content, 'enlighten' me with what you are trying to say
here? If you do not want to raise it why do you even bother mentioning
it? This just says "you are always complaining without explaining and
shut up about it" which reeks imho.

Greets,
 Jeroen

---

From: Jerome Durand <[email-masked]>
Date: Wed, 09 Mar 2005 13:53:39 +0100

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.

>   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

---

From: Tim Chown <[email-masked]>
Date: Wed, 9 Mar 2005 21:23:54 +0000

> is what the group should do I think. Thanks for that input.

We'll contact Florent directly.  I don't think there's any major issues,
just minor clarifications.  I think Florent already has input from others
long similar lines for the next revision.
 
> ...

I think for the sake for WG focus on the problem, I agree.  Whatever we
do, the TEP issue can be kept 'orthogonal' anyway.   I don't think v6tc
should deploy some solution (say reverse DNS as an example) when really
the discovery issue is wider than just TEP (else maybe each group
in this position will deploy a different style of solution, which would not 
be ideal).

-- 
Tim