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

On Wed, Nov 25, 2009 at 2:05 AM, Xu Xiaohu <xuxh@huawei.com> wrote:
>
>> -----邮件原件-----
>> 发件人: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] 代表
>> mohamed.boucadair@orange-ftgroup.com
>> 发送时间: 2009年11月13日 14:41
>> 收件人: Brian E Carpenter; behave@ietf.org
>> 主题: Re: [BEHAVE] draft-xu-behave-nat-state-sync-00
>>
>>
>> Dear all,
>>
>> I guess that the question should be asked priori to yours:
>>
>> Do we let vendors define their proprietary solutions or does the IETF define
>> a solution based on standardised protocols to achieve reliable state
>> synchronisation?
>
> For a small enterprise network, maybe it's acceptable to deploy two or more NAT boxes purchased from the same vendor for redundancy. However, for a large ISP network or large enterprise network, it is not reliable enough. For example, an abnormal packet will cause the router OS to crash, it is not absolutely acceptable. Hence I believe the standardization of NAT redundancy is necessary.
>

In the large scale NAT44 we run today, all vendors have 1+1
proprietary state sync.  They also sync configuration and other OAM
elements over this sync channel.  I do not think it is at all required
for vendors to have a standard state sync.  If I deploy multiple
vendors for NAT, i will keep the 1+1 pairs of the same vendor and use
different vendor 1+1 pairs for higher level network topology driven
redundancy, not local state synchronization.

Cameron Byrne
Principal Engineer
T-Mobile USA

> Xiaohu
>
>
>> From a service provider perspective, I'd like to see a solution with IETF stamp
>> so as to be included in our RFPs/analysis. Vendors are then free to propose
>> more reliable solutions, if any, compared to the one standardised by IETF.
>>
>> Cheers,
>> Med
>>
>>
>> -----Message d'origine-----
>> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de
>> Brian E Carpenter
>> Envoyé : vendredi 13 novembre 2009 02:55
>> À : behave@ietf.org
>> Objet : [BEHAVE] draft-xu-behave-nat-state-sync-00
>>
>> My question about this draft is whether there is available code and
>> implementation experience with SCSP, which was defined in 1998.
>>
>> If there isn't code and experience, since it is a quite complex design, I would
>> be a bit worried.
>>
>> On the other hand, I believe that something of the complexity of SCSP is
>> absolutely required to provide reliable synchronisation.
>> There is no simple, lightweight way to do this reliably.
>>
>>     Brian
>>
>> _______________________________________________
>> 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.
>> ********************************
>>
>> _______________________________________________
>> 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
>