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

Cameron Byrne <cb.list6@gmail.com> Tue, 01 December 2009 17:10 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AAB3A6A22 for <behave@core3.amsl.com>; Tue, 1 Dec 2009 09:10:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCotLUoRMGUt for <behave@core3.amsl.com>; Tue, 1 Dec 2009 09:10:36 -0800 (PST)
Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 5FB8B3A68E4 for <behave@ietf.org>; Tue, 1 Dec 2009 09:10:35 -0800 (PST)
Received: by ywh15 with SMTP id 15so4405812ywh.5 for <behave@ietf.org>; Tue, 01 Dec 2009 09:10:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PhFpjnct/L40FPhEQarSholfHHSNa5zLIh8vJ01xKwg=; b=UbgFZA2cvKjzbqteix1PYPZgdMSZnUhCAApni2jBQiCJqQLD1Zgo5N8hMOcRb1F+// dlNcQh6HVvoBN+qL9BxpxZ3Vfj1ORyNEgFPV/PPlBqYE+HBeAUxNIVQEe8Y6deLT4Ahj lJEOrFl+qnsrCB4v1CuyokFiDhl2sCCzdHU08=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=woGOAuOnxizcj5bv1TSsj7ZH2jRS/+2ncB5XzEBo38Z1oBxU6Y2hdvkdLX1pk24fAC 0LaMEylt815pUHI15c79alcRDA/8w2febBZGmrZKlUfueMyOnx8bCc/Fo4/IzCaCtV0y BkyJUGbvvWV7bOM5P6d18DRpqRtlR1dozczg4=
MIME-Version: 1.0
Received: by 10.150.129.27 with SMTP id b27mr10201399ybd.208.1259687420417; Tue, 01 Dec 2009 09:10:20 -0800 (PST)
In-Reply-To: <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com>
References: <bcff0fba0911302332ub498269qabbdca8341b018d5@mail.gmail.com> <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com>
Date: Tue, 01 Dec 2009 09:10:20 -0800
Message-ID: <bcff0fba0912010910t7f6fb313n58c9196b11d3fb77@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: Xu Xiaohu <xuxh@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org
Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2009 17:10:39 -0000

On Tue, Dec 1, 2009 at 1:07 AM, Xu Xiaohu <xuxh@huawei.com> wrote:
>
>
>> -----邮件原件-----
>> 发件人: Cameron Byrne [mailto:cb.list6@gmail.com]
>> 发送时间: 2009年12月1日 15:32
>> 收件人: Xu Xiaohu
>> 抄送: mohamed.boucadair@orange-ftgroup.com; behave@ietf.org
>> 主题: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re:
>> draft-xu-behave-nat-state-sync-00
>>
>> On Mon, Nov 30, 2009 at 8:19 PM, Xu Xiaohu <xuxh@huawei.com> wrote:
>> >
>> >
>> >> -----邮件原件-----
>> >> 发件人: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] 代表
>> >> Cameron Byrne
>> >> 发送时间: 2009年12月1日 1:19
>> >> 收件人: mohamed.boucadair@orange-ftgroup.com
>> >> 抄送: behave@ietf.org; 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,  <mohamed.boucadair@orange-ftgroup.com>
>> >> 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.
>
> In order to use the correct prefix64 in synthesizing AAAA records, the DNS64 should be able to determine which prefix64 is available by some means, e.g., exchanging messages with NAT64, or sending probe packets to a given IPv4 host within the IPv4 Internet by using different prefix64s.
>

Yes, i have suggested that the DNS64 SNMP poll the NAT64 to understand
its health and load (CPU, memory, active connections, ...).

> BTW, once the NAT box for a given prefix fails, would the communications using that prefix be interrupted till the corresponding AAAA records in the DNS caches of IPv6 hosts expire?
>

Yes, the host would have to re-query to the DNS64 unless we wanted to
provide the host with multiple AAAA responses with different addresses
synthesized from different pref64

> 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:cb.list6@gmail.com]
>> >> > Envoyé : jeudi 26 novembre 2009 18:43
>> >> > À : BOUCADAIR Mohamed NCPI/NAD/TIP
>> >> > Cc : Xu Xiaohu; Brian E Carpenter; behave@ietf.org
>> >> > 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,  <mohamed.boucadair@orange-ftgroup.com>
>> >> 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:cb.list6@gmail.com]
>> >> >> Envoyé : mercredi 25 novembre 2009 18:50
>> >> >> À : Xu Xiaohu
>> >> >> Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; Brian E Carpenter; behave@ietf.org
>> >> >> 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 <xuxh@huawei.com> wrote:
>> >> >>>
>> >> >>>> -----邮件原件-----
>> >> >>>> 发件人: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] 代
>> 表
>> >> >>>> mohamed.boucadair@orange-ftgroup.com
>> >> >>>> 发送时间: 2009年11月13日 14:41
>> >> >>>> 收件人: Brian E Carpenter; behave@ietf.org
>> >> >>>> 主题: 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 : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la
>> part
>> >> de
>> >> >>>> Brian E Carpenter
>> >> >>>> Envoyé : vendredi 13 novembre 2009 02:55
>> >> >>>> À : behave@ietf.org
>> >> >>>> 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
>> >> >>>> Behave@ietf.org
>> >> >>>> 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
>> >> >>>> Behave@ietf.org
>> >> >>>> https://www.ietf.org/mailman/listinfo/behave
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> Behave mailing list
>> >> >>> Behave@ietf.org
>> >> >>> 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
>> >> Behave@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/behave
>> >
>> > _______________________________________________
>> > Behave mailing list
>> > Behave@ietf.org
>> > https://www.ietf.org/mailman/listinfo/behave
>> >
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>