[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DSTM

On 24-jun-04, at 16:03, Bound, Jim wrote:

Multiple TEPs can be provided to the client for redundancy and router
failover deploying dual rail routers supports the mission critical case,
and if the link is cut or blown up there is custom software to inform
clients of that etc.

This sounds awfully complex to me... I'd rather take advantage of existing redundancy features such as VRRP.

Note I believe your concern applys to all transition mechanisms and do
we need to put this health warning on all transition mechanisms and in
our scenarios as we do security?

We are engineers; we build reliable networks from unreliable parts. So much goes without saying, or at least without saying it over and over untill we're all sick of hearing it... :-)

With security, every little thing must be secure. With redundancy, it's acceptable to have unreliable parts as long as you have several of them and switching from one to the other isn't too fatal. So I think those two issues are in different categories.

I'm not very comfortable with the phrase "all transition mechanisms" as most of the transition mechanisms that were created at one time or another turned out to be fairly useless ("automatich tunneling", 6over4, isatap). There is some risk that this will happen again now that we're looking at the other side of the coin (tunneling 6 over 4) unless we're very careful.

Again is this just picking on DSTM or
should the question be applied to all mechanisms (not mean't as negative
question just a question)? As a question of fair and open process?

I guess it depends. If there is stuff that's clearly useful and maybe even deployed, but there is no good way to add redundancy, so be it. On the other hand, if we have the choice between solving a problem in a way that allows for redundancy and in a way that doesn't, then it makes sense to go with the redundancy-friendly way.

With regard to DSTM: I applaud the goal, but I'm doubtful if the way to get there is the optimal one, for the reasons listed earlier, and also because having some special purpose software handling all kinds of details isn't very attractive (to me at least), as opposed to having a more generic encapsulation mechanism over which we can run a variety of existing mechanisms such as ARP, DHCP and VRRP.

But I understand you guys already have code. I guess the best way forward would be to deploy this code and see how well it behaves in the real world. If it turns out it works very well, we should probably standardize it, even if there are theoretical flaws. On the other hand, if the issues I pointed out and/or others turn out to be of concern in practice, we may want to start from scratch at some point in the future, heeding the lessons learned.

In DSTM it is assumed that an IPv4 address from the DNS returned which
begins the DSTM client the TSP or DHCPv6 or RPC to the server will match
correct TEP and CIDR or IPv4 high order bits of address for network
route.

??? I don't understand. If I connect to more than one IPv4 destination, do I talk to more than one tunnel endpoint? That doesn't make sense.