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

I believe we have agreed that we want to support the configuration of 
multiple stateful NAT64s in a cluster sharing state (using the same 
prefix, backing each other up / sharing load / ... ).

While it is true that one can deploy that with solutions from a single 
vendor, it seems natural and consistent with the rest of what we do here 
that we want to allow folks to build such a cluster using devices from 
different vendors.  Arguing about why an operator might or might not do 
that is a waste of time.  Some will want multiple vendors.  Some will 
want a single vendor.  Some will want the ability to migrate to a new 
vendor.

For the IETF therefore, the protocol for the state sharing seems a 
sensible thing to standardize.

Yours,
Joel

Cameron Byrne wrote:
> 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.
> 
> 
>> 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
> 