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

[marcelo bagnulo braun <[e-mail]>]

Xu Xiaohu escribió:
>   
>> -----邮件原件-----
>> 发件人: [e-mail] [mailto:[e-mail]] 代表
>> Cameron Byrne
>> 发送时间: 2009年11月26日 1:50
>> 收件人: Xu Xiaohu
>> 抄送: [e-mail]; [e-mail]
>> 主题: 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 <[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.
>>     
>> 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....

regards, marcelo


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