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

[Xu Xiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: [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

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