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

[Xu Xiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: Dan Wing [mailto:[e-mail]]
> 发送时间: 2009年11月26日 10:11
> 收件人: 'Reinaldo Penno'; 'Xu Xiaohu'; [e-mail];
> 'Brian E Carpenter'; [e-mail]
> 主题: 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?
> 
> If everyone everyone implements NAT44 or NAT64 the same (which they
> won't), there will still be differences in pps vs. bandwidth
> vs. new-mappings-per-second.

I think the RFP and the testing before purchase could help the customers choose a good match from various NAT boxes of different vendors.

Xiaohu

> -d
> 
> 
> > 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" <[e-mail]> wrote:
> >
> > >
> > > -----邮件原件-----
> > > 发件人: [e-mail]
> > > [mailto:[e-mail]] 代表
> > > [e-mail]
> > > 发
> > > 送时间: 2009年11月13日 14:41
> > > 收件人: Brian E Carpenter; [e-mail]
> > > 主题:
> > > 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 : [e-mail] [mailto:[e-mail]]
> > > De la part de
> > > Brian E Carpenter
> > > Envoyé : vendredi 13 novembre 2009 02:55
> > >
> > > À : [e-mail]
> > > 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
> > > [e-mail]
> > >
> > > 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
> > >
> > > [e-mail]
> > >
> > > https://www.ietf.org/mailman/listinfo/behave
> >
> > ________________________________
> > > _______________
> > Behave mailing
> > > list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave
> >
> >
> > _______________________________________________
> > Behave mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave
> >