Re: [BEHAVE] [Behave] Re: Some comments about draft-chen-behave-rsnat-00

<mohamed.boucadair@orange-ftgroup.com> Wed, 22 July 2009 07:39 UTC

Return-Path: <mohamed.boucadair@orange-ftgroup.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 8860D3A6B93 for <behave@core3.amsl.com>; Wed, 22 Jul 2009 00:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.784
X-Spam-Level:
X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=-1.466, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, 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 coXQHdz6tJgc for <behave@core3.amsl.com>; Wed, 22 Jul 2009 00:39:36 -0700 (PDT)
Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 1A9413A6906 for <behave@ietf.org>; Wed, 22 Jul 2009 00:39:34 -0700 (PDT)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 09:38:15 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0A9F.58218FDF"
Date: Wed, 22 Jul 2009 09:38:02 +0200
Message-ID: <08BA2C59E081884DB2AAE4A0BE9D6DC13FA965@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <36ba02b00907210904l6f43d50bn916bbfa4f1923bd3@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Behave] Re: Some comments about draft-chen-behave-rsnat-00
Thread-Index: AcoKHPukbg6a5t1oRpyLu5E+Vwwb1gAgYazw
References: <08BA2C59E081884DB2AAE4A0BE9D6DC13FA6E1@ftrdmel0.rd.francetelecom.fr> <36ba02b00907210904l6f43d50bn916bbfa4f1923bd3@mail.gmail.com>
From: mohamed.boucadair@orange-ftgroup.com
To: phdgang@gmail.com
X-OriginalArrivalTime: 22 Jul 2009 07:38:15.0517 (UTC) FILETIME=[5FB3B0D0:01CA0A9F]
Cc: denghui02@gmail.com, xmw@csnet1.cs.tsinghua.edu.cn, behave@ietf.org, songlinjian@csnet1.cs.tsinghua.edu.cn, zhouboyj@chinamobile.com, cuiyong@tsinghua.edu.cn
Subject: Re: [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: Wed, 22 Jul 2009 07:39:46 -0000

Dear Gang, all,
 
Please see inline.
 
Cheers,
Med
 

  _____  

De : Chen Gang [mailto:phdgang@gmail.com] 
Envoyé : mardi 21 juillet 2009 18:05
À : BOUCADAIR Mohamed RD-CORE-CAE
Cc : cuiyong@tsinghua.edu.cn; songlinjian@csnet1.cs.tsinghua.edu.cn; xmw@csnet1.cs.tsinghua.edu.cn; zhouboyj@chinamobile.com; denghui02@gmail.com; Behave WG
Objet : [Behave] Re: Some comments about draft-chen-behave-rsnat-00



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.


[Med] This needs to be elaborated in the text. 

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

[Med]  I think that providing a set of parameters to qualify scalability is useful.
 
   [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?
[Med] No. Only mention that both cases can exist. 
 
[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?
[Med] the capability attribute is required to prevent session failure when one of the BGP speakers do not support the @ mapping attribute. 
 
    [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  <http://www.wiley.com/remtitle.cgi?isbn=9780470770726> SIP-Enabled Networks