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

> -----邮件原件-----
> 发件人: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] 代表
> Cameron Byrne
> 发送时间: 2009年12月2日 12:37
> 收件人: Dan Wing
> 抄送: behave@ietf.org; Xu Xiaohu
> 主题: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re:
> draft-xu-behave-nat-state-sync-00
> 
> On Tue, Dec 1, 2009 at 6:06 PM, Dan Wing <dwing@cisco.com> wrote:
> > ...
> >> > * 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?
> >
> > The vendor fixes the bug.
> >
> 
> 100% agree.  The counter to Xu Xiaohu's point is what happens when
> vendor X sends a buggy sync update to vendor Y, and now vendor Y
> crashes.... ok.  We traded one unlikely (but real) bad situation for
> another unlikely but bad situation.

Aha, as long as the router from vendor X is still available, that would be OK. Maybe you would say later how about if router X kills itself after making router Y crash. Just a joke!  ^_^

Xiaohu

> > The operational complexity of running two NATs, from two different vendors,
> is
> > very high:  different CLIs, different alarming/alerting (e.g., SYSLOG,
> SNMP,
> > per-session NAT logging), different features (e.g., IPsec Passthru, SCTP),
> > different implementation of features (e.g., TCP MSS adjustment,
> fragmentation
> > [timeouts?  how much memory dedicated to reassembly?  out-of-order packets
> > supported?]), bandwidth and throughput (Mbps, pps),  make it too hard to
> > operate both NATs.
> 
> 100% agree.
> 
> >
> > To my knowledge, sites do not run two different implementations of DNS servers
> > (e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both DNSs back
> > up each other.  Like NAT, DNS needs to be rock-solid reliable, and a single
> > packet could take out a DNS server.
> >
> > -d
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> >
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave