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

-----Message d'origine-----
De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Joel M. Halpern
Envoyé : mercredi 2 décembre 2009 05:46
À : Cameron Byrne
Cc : behave@ietf.org; Xu Xiaohu; Dan Wing
Objet : 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.

Med: I fully agree.

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
> 
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************