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