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

From: Chen Gang <[email-masked]>
Date: Wed, 22 Jul 2009 00:04:49 +0800

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 <[email-masked]>

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

---

From: <[email-masked]>
Date: Wed, 22 Jul 2009 09:38:02 +0200

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

  _____  

De : Chen Gang [mailto:[email-masked]] 
Envoyé : mardi 21 juillet 2009 18:05
À : BOUCADAIR Mohamed RD-CORE-CAE
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Behave WG
Objet : [Behave] Re: Some comments about draft-chen-behave-rsnat-00

Hello mohamed ,

   [original text]However much of the NAT-like functions are stateful, which maintain

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

=> "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.

=>Agree. Are you suggesting to remove this functions?
[Med] No. Only mention that both cases can exist. 

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

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

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

BRs
 
-Gang

Dear authors,

Cheers,
Med

France Telecom R&D
CORE/M2V/EVI
42, rue des coutures
BP6243
14066 Caen Cedex France 

**Out now!**

Read more and buy online at Inter-Asterisk Exchange (IAX): Deployment Scenarios in  <http://www.wiley.com/remtitle.cgi?isbn=9780470770726> SIP-Enabled Networks

---

From: Chen Gang <[email-masked]>
Date: Wed, 22 Jul 2009 18:56:29 +0800

Hello Med,

My reply is inline.

Thanks.
2009/7/22 <[email-masked]>

> situation without this mechanisms.
 [Med]  I think that providing a set of parameters to qualify scalability is
> useful.

=> It could be better. Could you propose some text on that?

> [Med] the capability attribute is required to prevent session failure when
> one of the BGP speakers do not support the @ mapping attribute.
>

=> I guess adding a new capability attributes is an alternative solution to
switch mapping information. However, corresponding to the new capablity
attribute, we might need to define respective message and extend the error
handling. Compared to that, extending path attribute might more easily be
deployed.  Actually, the redundancy mechanisms only need best-effort
performance.

Thanks for your constructive comments.

Gang