Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

[Xu Xiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表
Simon
> Perreault
> 发送时间: 2009年12月2日 3:16
> 收件人: Dan Wing
> 抄送: [e-mail]
> 主题: Re: [BEHAVE] proprietary implementation v.s
standardisedprotocols//re:
> draft-xu-behave-nat-state-sync-00
> 
> Dan Wing wrote, on 2009-12-01 13:39:
> > My point is that it shouldn't make things worse.  If the functioning
> > NAT64's prefix changes and the old prefix no longer works, that makes
> > things worse -- it effectively causes IPv6 addresses to change.  That
> > breaks not just applications that are sensitive to IP address changes,
> > but also existing TCP sessions.  SCTP handles IP address changes
> > better, but there is scant deployment of SCTP yet (due to many
> > reasons).
> 
> I don't understand where you're going.
> 
> There are two kinds of breakage:
> 
> 1. One NAT64 box in a cluster* dies. No impact beyond the fact that you
now
> have
> a dead box that needs replacing.
> 
> 2. A whole cluster dies. This is not pain-free, and it's not designed to
be.
> Suddenly, you need to redirect all clients to the new Pref64::/n. There
are
> known issues with that, but this event will happen rarely enough that it's
worth
> the risk.
> 
> If you're really afraid of breakage #2, you have to use bigger clusters.
But
> that has disadvantages too. It ends up being an operational issue.
Tradeoffs,
> etc.
> 
> Another idea: have another cluster "take over" the prefix of the dead one.
Use
> routing to redirect clients to the new cluster. Tradeoffs, etc., again.
> 
> My point is that #2 doesn't need standardization. The solutions are
diverse
> and
> everyone will be dealing with it differently. On the other hand, #1 is a
well
> understood problem, with a well understood solution, with various
proprietary
> incarnations in use right now (hint! hint!).
> 
> 
> * Cluster = A set of synchronized NAT64 boxes sharing a single Pref64::/n.

Does that mean a set of NAT64 boxes within a cluster should be from a single
vendor? If so, how to deal with the case that some abnormal packets cause
NAT boxes (using the same OS) within a cluster to crash simultaneously due
to a bug with that OS?

Xiaohu