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

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

I think we are basically exploring whether it is worth (and if it is 
possible) to standardize a  protocol to synchronize nat state.

The reason for doing that is that as you mention, there is a vlaue in 
allowing multiple boxes from multiple vendors to be used in synch i.e. 
interoperability.

The reasons for not doing so are less obvious i agree.

the main reason that i have encountered in a similar situation is that 
people that implement these boxes ar enot interested in doing so, so if 
we try to do this work, we end up without the required expertise to do 
it right.

You may ask then why vendors are not interested in doing this.
I guess that there are two lines of arguments here. First that in order 
to make a high availability system, the protocol needs to exchange state 
that is closely related to the particular implementation, so as it is 
very implementation dependent, it is not possible to do a standard 
protocol that works as fine as the proprietary one.
So, they claim that is one key differentiating factor, and that they 
don't want to loose it. Well, basically in general vendors preffer their 
own propiertary implementations, i guess. So, the real answer there is 
that it is likely to be because there is not enough pressure from the 
customers for this particular feature. If clients considered that having 
multiple interoperable boxes from different vendors is very important, 
maybe vendors would be more interested in doing this.

So, in summary, i personally don't have a position yet. However, it is 
clear to me that a very bad case is one where we end up with the WG 
chartered to do this and there is no vendor that has actual 
implementations of these boxes working and reviewing this work i.e. we 
don't have the right expertise for this. So, i would be in favour of 
doing this, only if we have a few vendors that are willing to work on this.

Hope it makes sense

Regards, marcelo



Joel M. Halpern escribió:
> I am having trouble figuring out what this discussion is about.
> We standardize protocols to enable interoperation.
> Unless there is something special that requires that distinct devices 
> come from the same vendor, we assume that they may come from different 
> vendors, and that is why there is value in our work.
>
> Whether a given operator chooses to use multiple vendors, or chooses 
> to use one vendor, is a tradeoff made by that (enterprise, edge, or 
> core) operator.  One could have (and folks have) exactly the same 
> debate about routing protocols.
>
> Yours,
> Joel
>
> marcelo bagnulo braun wrote:
>> 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
>>>   
>>
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave