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

If the boxes are from different vendors or even different platforms from the
same vendor, how to deal with issues such as different memory footprint for
NAT state, different NAT implementations, different processor speeds, etc?

Most NAT redundancy schemes are 1+1 because the implementation specific
issues above preclude a heterogeneous solution.

Thanks,

Reinaldo

On 11/25/09 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.

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