Re: DSTM

["Todd T. Fries" <todd@fries.net>]

It seems strange to me that VRRP is mentioned on a v6ops mailing list
when, as far as I have been lead to believe, VRRP does not support V6.

CARP, on the other hand, does.

On Thu, 2004-06-24 at 16:47 +0200, Iljitsch van Beijnum wrote:
> 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.
>