[BEHAVE] [Behave] Re: Some comments about draft-chen-behave-rsnat-00
Chen Gang <phdgang@gmail.com> Tue, 21 July 2009 16:05 UTC
Return-Path: <phdgang@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 0DE9428C287 for <behave@core3.amsl.com>; Tue, 21 Jul 2009 09:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.283
X-Spam-Level:
X-Spam-Status: No, score=0.283 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_47=0.6]
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 aDr-6Sl4kmw4 for <behave@core3.amsl.com>; Tue, 21 Jul 2009 09:05:29 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 2A6523A6881 for <behave@ietf.org>; Tue, 21 Jul 2009 09:05:28 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 28so978964wff.31 for <behave@ietf.org>; Tue, 21 Jul 2009 09:04:49 -0700 (PDT)
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; bh=FQE8RziEz74VLRy229V3lBD51A7Nc96RW/FS1m8+gw8=; b=q3NPQy3cWrHvLcIBUjZhqPzBq5bB/dyT6txdJJ8tGnCfysvlMdKLrtwXkAg/CI5jMH /8sMlpmLateR9VDQvSSBKJNWw+0+4BG6TWJ8bxJcsnbvRH2nMH3T8vudj337zU/KpAan 41heRklpGGat21I9x+IfRze923D5mEF/vyfh0=
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; b=KwuN4VMVamD9qA1q+O09KLuthT63mStWdV3v3pDyolTmEcCLBFjADgjrSeMaRIau+O j8wZ0nyagzhBybOLBhicqYVFp8j3y4eCKZyZ2yGNdSNr865P5BDXzUzkztbGvCPpoKBl KGZlezB/X90DlB0fiAwmIzonaVwTAAUuTOcH4=
MIME-Version: 1.0
Received: by 10.142.241.15 with SMTP id o15mr1470888wfh.264.1248192289491; Tue, 21 Jul 2009 09:04:49 -0700 (PDT)
In-Reply-To: <08BA2C59E081884DB2AAE4A0BE9D6DC13FA6E1@ftrdmel0.rd.francetelecom.fr>
References: <08BA2C59E081884DB2AAE4A0BE9D6DC13FA6E1@ftrdmel0.rd.francetelecom.fr>
Date: Wed, 22 Jul 2009 00:04:49 +0800
Message-ID: <36ba02b00907210904l6f43d50bn916bbfa4f1923bd3@mail.gmail.com>
From: Chen Gang <phdgang@gmail.com>
To: mohamed.boucadair@orange-ftgroup.com
Content-Type: multipart/alternative; boundary="000e0cd1469006ce13046f396ae0"
Cc: denghui02@gmail.com, xmw@csnet1.cs.tsinghua.edu.cn, Behave WG <behave@ietf.org>, songlinjian@csnet1.cs.tsinghua.edu.cn, zhouboyj@chinamobile.com, cuiyong@tsinghua.edu.cn
Subject: [BEHAVE] [Behave] Re: Some comments about draft-chen-behave-rsnat-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, 21 Jul 2009 16:05:31 -0000
Hello mohamed , I have transformed your comments into the text which is shown in below. I guess that could be more easily read and reply. [original text]However much of the NAT-like functions are stateful, which maintain the state of address mapping for network translation or ALG function. The stateful boxes in the network exert high threat on reliability and scalability when the network becomes huge. For example the box will be single point of failure in the large scale Network. Although some advices are proposed such as mentioned in NAT64 using multi-boxes, the static configuration and localized mapping information in each box are not able to accommodate the dynamic internet environment. [comments]: "NAT-like" needs to be defined => NAT is an common concept. "NAT-like" indicates an general functionality, which includes both IPv4 NAT and IPv4/IPv6 NAT. In order to avoid ambiguity, we might replace "NAT-like functions" with "translator functionalities". Hope that would be clear. [original text]In this document, we propose a reliable and scalable NAT mechanism to overcome the stateful NAT problem mentioned above, which include IPv4 NAT and IPv4/IPv6 NAT. Note that the stateless NAT mechanism IVI [I-D.baker-behave-ivi], and its limitation is out the scope of this document. [comments]: Does "reliable" mean that full fail over mechanism is proposed when a statefull NAT box is out of service? Otherwise, the term should be defined. "Scalable" needs to be defined in this document: which parameters are used to assess the scalability, etc. => The terms "reliable" and "scalable" is a sort of qualitative definition other than quantitative indicators. Therefore, it's hard to find some paremeters to evaluate. The evaluation could be made compared to the situation without this mechanisms. [original text]The User Network and Service Network are logical concepts, which may be composed of many small networks in one AS or several ASes[BM1] [comments]A customer network is not necessarily an AS. Please define what you mean by “User Network”. At this stage, it is unclear to me. => We for sure need to defined the new terms. User Network indicates a network, in which hosts will initiate a service call. And then, servers located in Service Network will receive the applciation query and make a reply. In P2P mode, a initiator and a receiver can be exchangeable. Therefore, the definition of network roles is depending on a specific communication scenario. [original text]the RS-NAT box should have three basic functions: the support of IPv4/IPv6 dual-stack, routing functions and IPv4/IPv6 address translator. [comments]What does "the support of IPv4/IPv6 dual-stack"mean ? => "the support of IPv4/IPv6 dual-stack" means the RS-NAT box is capable of dual-stack, involving running IPv4 and IPv6 at the same time. [comments]Note that routing functions can be outsourced to a third party. =>Agree. Are you suggesting to remove this functions? [comments]Not only address translator : new IP headers are generated. =>IP headers generation is involved in IP header translation process. so, this functionalities have already been covered by the address translator. [original text]The first problem is in routing aspect: when one box fails, there is no other valid routes to the destination. [comments] Because the assumption is that the box is an IGP(/BGP) speaker. Right? => Not really. Since a translator box maintain a mapping informaiton for each traffic, which will go through the translator. When translator fails, the mapping information will lose. Even the back flow can reach another box, but there is no mapping information to serve the traffic. Hereby, the traffic will be agnostic for their destionation address. [original text]The first problem is solved in Section 4 in that the routing mechanism makes sure that the traffic will find a way out through another RS-NAT router by setting the different route cost or preference. In this section, we define a BGP attribute to be used by a RS-NAT to advertise the local address mapping to other neighbors which guarantees the redundancy of mapping info. [comments]A refresh time should be set. =>You are right. We will study a refresh rules for mapping informatio update. Otherwise, RS-NAT box performance will be deteriorated due to frequent mapping update. The refresh rules will be supplemented in next version of the draft. [original text]5.1. Address mapping Attribute Address mapping attribute is an optional transitive attribute that is composed of a set of TLVs. The type code of the attribute is to be assigned by IANA. Each TLV contains information corresponding to a particular tunnel technology. The TLV is structured as follows: [comments]A new BGP capability attribute should also be defined to avoid session failure when not supported by both BGP speakers. => What does the "new BGP capability attribute" mean? Is new path attribute not enough to carry mapping information? [original text] - IPv4-IPv4: mapping Type = 1 - IPv4-IPv6/IPv6-IPv4: mapping Type = 2 - IPv6-IPv6: mapping Type=3 [comments] What is the usage of "IPv6-IPv6" ? =>The usage can refer to draft-mrw-behave-nat66-02.txt. It is ongoing work. [comments]In the context of DS-lite NAT, another type is required :IPv6@, private IPv4@, public IPv@, + other info. => Agree. We will extend mapping type to support DS-Lite NAT. [original text] Value (variable): The value is composed of the address mapping information. If mapping type is 2, the value contains an IPv4/6 address mapping just simply structured as follows: [comments]Why port information is not inserted in the mapping ? Did I missed something? If the purpose is only to react in case of session failure (but without maintaining session states), then I guess your introduction text should be clarified. => I guess port information is useful for NAPT case and other port-sharing case. The listed address mapping value is corresponding to mapping type 2 (e.g. IPv4-IPv6/IPv6-IPv4 translation). The latest draft may lack of some value information definition related to type 1 and type 3. Thanks for the discussion. BRs -Gang 2009/7/21 <mohamed.boucadair@orange-ftgroup.com> > Dear authors, > > Please find attached some comments and modifs to your draft. > > Cheers, > Med > > > > France Telecom R&D > CORE/M2V/EVI > 42, rue des coutures > BP6243 > 14066 Caen Cedex France > > ***Out now!*** > > Inter-Asterisk Exchange (IAX): Deployment Scenarios in SIP-Enabled Networks > > Read more and buy online at Inter-Asterisk Exchange (IAX): Deployment > Scenarios in SIP-Enabled Networks<http://www.wiley.com/remtitle.cgi?isbn=9780470770726> > > > >
- [BEHAVE] [Behave] Re: Some comments about draft-c… Chen Gang
- Re: [BEHAVE] [Behave] Re: Some comments about dra… mohamed.boucadair
- Re: [BEHAVE] [Behave] Re: Some comments about dra… Chen Gang