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

> -----邮件原件-----
> 发件人: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] 代表
> Cameron Byrne
> 发送时间: 2009年11月26日 1:50
> 收件人: Xu Xiaohu
> 抄送: behave@ietf.org; mohamed.boucadair@orange-ftgroup.com
> 主题: 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.

There is a possibility that some abnormal packets could cause the two NAT boxes (using the same OS) to crash simultaneously due to a bug in that OS. I know this is an infrequent case which is acceptable for small enterprise networks. However, I wonder whether this failure is acceptable for all ISPs who deploy large scale NATs?

Xiaohu

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