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

> -----邮件原件-----
> 发件人: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]
> 发送时间: 2009年11月26日 15:42
> 收件人: Xu Xiaohu
> 抄送: 'Cameron Byrne'; mohamed.boucadair@orange-ftgroup.com; behave@ietf.org
> 主题: Re: [BEHAVE] proprietary implementation v.s standardised protocols//re:
> draft-xu-behave-nat-state-sync-00
> 
> Xu Xiaohu escribió:
> >
> >> -----邮件原件-----
> >> 发件人: 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.
> 
> the counter argument, is that if you have multiple implementation you
> end up with the union of the sets of bugs of all implementations....

Yes. However, as long as these bugs of different implementations are not triggered by the same condition, it is safe.

There was a famous words, "Don't put all eggs in one basket."

Xiaohu

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