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

["Joel M. Halpern" <[e-mail]>]

While it is true that state sync can not keep up with everything.  (As 
Cameron says, if the state changes faster than the synchronization, it 
just won't be synchronized.)
That does not mean that we should not address synchronization.  It just 
means we have to be clear about what we canaccomplish.  Part of the 
reason this is, to my mind, acceptable is that the same connections that 
are too fast for the synchronization are the ones that don't need it. 
They can cope with reestablishing.  It is the longer-lived 
communications which benefit from synchrony and which can be supported 
by it.

Given that it is valuable to support synchrony, it seems sensible to 
standardize it.

With regard to NAT44, I can see the argument that there are too many 
variations to handle everything.  So lets use the taxonomy and at least 
include the large piece that easily and naturally fits.  (Namely, full 
cone.)  Lets document what we have, and not go crazy trying to cover all 
possible cases.

Again, the point is to define something that improves interoperability 
for common, useful, cases.  There seems to be a fairly large, and easily 
addressed, space there.  And we can address it in a fashion that is not 
dependent upon whether it is 1+1, N+1, or N load-sharing.

Yours,
Joel

Cameron Byrne wrote:
> On Thu, Nov 26, 2009 at 12:04 AM,  <[e-mail]> wrote:
>> Dear Cameron,
>>
>> This may be true for 1+1 redundancy schemes, but what about N+1 ones?
>>
>> Cheers
>> Med
>>
> 
> One more point, macro-level state sync is not solvable problem.  In
> today's world of RSS and AJAX, the session growth is in many short
> sessions.  Sessions that are so short they  last less than 1 second.
> Even the locally connected state sync cannot really keep up with
> pushing the state table (millions of connections) between a pair of
> NAT boxes in real time.  State-sync will be much less effective across
> a WAN, and much much less effective in 1 + N or N +N in a WAN.  The
> vendors i have talked to remain cautious about their ability to scale
> 1+1 without impacting overall system capacity, and when i say i am
> concerned about performance they tell me to turn off state sync.
> 
> State sync is a very large implementation challenge for vendors, the
> specific challenges are box specific, and i do not think the IETF can
> meaningful improve this situation with yet another draft / protocol.
> 
>> -----Message d'origine-----
>> De : Cameron Byrne [mailto:[e-mail]]
>> Envoyé : mercredi 25 novembre 2009 18:50
>> À : Xu Xiaohu
>> Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; Brian E Carpenter; [e-mail]
>> Objet : 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.
>>
>> Cameron Byrne
>> Principal Engineer
>> T-Mobile USA
>>
>>> 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
>>>
>> *********************************
>> 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