Re: [v6tc] Re: Tunneling and Transition Drafts

[Thomas Narten <[e-mail]>]

> The only thing you need is a well known anycast IP address where your
> clients can find the TSP server at.

I keep hearing this like its a slam-dunk obvious solution. It is not
(at least not if I listen to what some other people say). The use of
anycast addresses for service discovery is controversial. Do the words
"dns discovery" bring to mind anything about the obviousness and
likeliness of having quick success of choosing this solution?
Everytime you (or anyone else - not picking on you in particular)
brings up this approach are you also oblivious to other folk that
don't think this is a reasonable way to go?

> Just in case people wonder why I did not go with TSP: it did not fulfill
> the various requirements we had, like being able to use it to turn
> tunnels on/off, move tunnels and a lot of other things,

What does "move tunnels" mean?

Also, it would be useful if you would specify the "lot of other
things", so we could understand better what the real requirements are.

> in a command oriented way, thus without having to use/depend on xml.

It's not immediately obvious to me what "without having to use/depend
on xml" has to do with "command oriented way". How commands are
implemented underneath doesn't have to be visible to the user
interface.

> Could the people who 'require' an alternate solution than TSP, specify
> what the problems are with it and possibly list what their proposed
> solution* would be?

Actually, I prefer just the "what is the problem part". We have enough
of an issue where the problem is "handwave handwave", but "my pet
solution" solves the problem perfectly.

Thomas

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