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

[Cameron Byrne <[e-mail]>]

On Mon, Nov 30, 2009 at 8:19 PM, Xu Xiaohu <[e-mail]> wrote:
>
>
>> -----邮件原件-----
>> 发件人: [e-mail] [mailto:[e-mail]] 代表
>> Cameron Byrne
>> 发送时间: 2009年12月1日 1:19
>> 收件人: [e-mail]
>> 抄送: [e-mail]; Xu Xiaohu
>> 主题: Re: [BEHAVE] proprietary implementation v.s standardised protocols//re:
>> draft-xu-behave-nat-state-sync-00
>>
>> On Mon, Nov 30, 2009 at 4:54 AM,  <[e-mail]>
>> wrote:
>> >
>> > Dear Cameron,
>> >
>> > The issue you are describing is more about load distribution rather than NAT
>> state sync.
>>
>> Correct, i believe we can best provide service availability in the
>> macro network with DNS64 controlled load distribution.  NAT sync in
>> the macro network faces too many challenges to be useful
>
> Do you want to use DNS64 to achieve NAT redundancy while realizing load-balancing? Do you mean offering the IPv6 host another prefix64 by DNS64 if the NAT box for the previous prefix crashes?
>
> Xiaohu

Yes, I want DNS64 to facilitate NAT64 redundancy from a macro-network
perspective while also providing load-sharing. Load sharing and
redundancy are frequently coupled (web server farms, sip proxies,
anycast DNS servers ...).  This solutions is only focused on AAAA
query responses to an IPv6-only host from a DNS64, which in my
use-case is the most common scenario.  Other use-cases do not interest
me as much and may better fit a well know anycast prefix64.

Cameron

>
>> > 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.
>> >
>>
>> Unfortunately, i have yet to find an useful application for stateless
>> NATxy in my network.  The NAT44 i have deployed today require
>> multiplexing many users behind a small pool public IP address.
>> Changing the source from IPv4 to IPv6 will face the same limitation
>> that requires multiplexing many users behind a few IPv4 addresses and
>> consequently requires a stateful multiplexed solution.
>>
>> Regarding symmetrical flows, I don't really understand your comment.
>> I don't support the idea of macro network state sync, and i do see
>> that people who try to deploy that will have a symmetry issue.
>>
>> My expectation is that each stateful NAT64 (local 1+1) with a unique
>> PREF64 will advertise a unique IPv4 prefix, so the flows are always
>> symmetric.  The entire network has many stateful NAT64 (local 1+1) and
>> the translation load and resiliency is solved by distributing these
>> autonomous building blocks of capacity and availability throughout the
>> network.
>>
>> > 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.
>> > ********************************
>> >
>> >
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>