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

[<[e-mail]>]

Dear Cameron, 

The issue you are describing is more about load distribution rather than NAT state sync.

I agree with the requirement you have (BTW, similar solutions exist for the selection of the outbound proxy SIP) but this may be easy to implement with stateless NATxy rather than stateful one since the path MUST be symmetric (the same NAT device must be crossed) and appropriate routing actions should be undertaken to redirect the traffic to the appropriate NATxy device. If you have a fully distributed NATxy and all advertise the same IPv4 net, then the symmetry requirement is difficult to meet. Not to mention that the load should be controlled in both sides of the NAT.

Cheers,
Med


-----Message d'origine-----
De : Cameron Byrne [mailto:[e-mail]] 
Envoyé : jeudi 26 novembre 2009 18:43
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Xu Xiaohu; Brian E Carpenter; [e-mail]
Objet : Re: [BEHAVE] proprietary implementation v.s standardised protocols //re: draft-xu-behave-nat-state-sync-00

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?

In other threads i have proposed using multiple  NAT64 / PREF64 pairs
handed out by the DNS64, and having feedback from the NAT64 to the
DNS64 to communicate health of NAT64 box such that the PREF64 can be
taken out of rotation if needed by the DNS64.  This is how global site
load balancing works today for web sites and CDNs.  I do expect this
type of implementation to have NAT64 in 1+1 for local instant fault
tolerance and the DNS64 to be a more macro level recovery and load
sharing technique

If can't get it into the standard, i can get a vendor to do it.  And,
if i can't get a vendor to do it i can probably rig it myself with a
perl script to SNMP poll the NAT64 for health and load and reset the
DNS64 config automatically to redirect traffic from bad PREF64 /
NAT64s to good PREF64 NAT64s

I know the tricks that global site load balancing does are not pure,
but my perpective is that this is the reality of the internet, it is
the only way google, facebook, yahoo can scale.  It is the only way
NAT64 can scale linearly as a system of hardware building blocks and
survive at a macro level.

Cameron

>
> Cheers
> Med
>
>
> -----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.
> ********************************
>
>

*********************************
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.
********************************