Jump to: navigation, search

Difference between revisions of "Talk:L3-ext-gw-modes-spec"

(Created page with "''nati-ueno'': There is usecase we need SNAT or DNAT on the others port. How about keep external_network_info with current form and add, dnat_ports= [ port_id1,port_id2.....")
 
 
(One intermediate revision by one other user not shown)
Line 4: Line 4:
 
How about keep external_network_info with current form and add,
 
How about keep external_network_info with current form and add,
  
dnat_ports= [
+
  dnat_ports= [
  port_id1,port_id2...
+
    port_id1,port_id2...
]
+
  ]
snat_ports= [
+
  snat_ports= [
  port_id1,port_id2...
+
    port_id1,port_id2...
]
+
  ]
  
 
''salvatore-orlando'':
 
''salvatore-orlando'':
Line 18: Line 18:
 
* List attributes are always a bit tricky for API users (when you do a PUT you replace the whole list, so you need to do a GET first). I'm not saying we should not have them, but if we have an easy alternative, there's probably a point to choose the alternative.
 
* List attributes are always a bit tricky for API users (when you do a PUT you replace the whole list, so you need to do a GET first). I'm not saying we should not have them, but if we have an easy alternative, there's probably a point to choose the alternative.
 
* On a slightly unrelated note, when we do apply NAT to interface different from the gateway, does it make sense binding it to ports? Or is the concept more similar to the 'extraroute' extension? In that case you would have a list of SNAT/DNAT rules which apply to the router as a whole.
 
* On a slightly unrelated note, when we do apply NAT to interface different from the gateway, does it make sense binding it to ports? Or is the concept more similar to the 'extraroute' extension? In that case you would have a list of SNAT/DNAT rules which apply to the router as a whole.
 +
 +
"nati-ueno"
 +
 +
Thank you for your reply.
 +
I agree with your points.
 +
so how we can support more advanced SNAT/DNAT configuration?
 +
Now, we have two options.
 +
 +
[Option1] attribute on router port ( with Marks patch ) 
 +
    enable_snat
 +
    enable_dnat
 +
 +
[Option2] SNAT/DNAT list
 +
 +
On the iptables we can combine source ip / dest ip / source port/ dest port with protocol with SNAT/DNAT.
 +
However this may be too mach for tenant facing apis.
 +
if we can use floating ip for each port, I'm +1 for Option1.

Latest revision as of 12:33, 29 March 2013

nati-ueno:

There is usecase we need SNAT or DNAT on the others port. How about keep external_network_info with current form and add,

 dnat_ports= [
    port_id1,port_id2...
 ]
 snat_ports= [
    port_id1,port_id2...
 ]

salvatore-orlando:

This is a valid argument - and also a very reasonable use case - , but I am not sure whether it would be the right API approach or not.

  • The external_network_info attribute was conceived as a dict rather than a single attribute for the purpose of allowing user to specify more properties - enabling and disabling snat are just an example of such properties.
  • The declaration of lists of ports on which one wants to do snat/dnat implies a concept of router port, that we unfortunately lack. The blueprint https://blueprints.launchpad.net/quantum/+spec/l3-router-port-relationship proposes to add such concept. Once we have this concept, enable_snat and enable_dnat might become attributes of the router port, which is probably easier than handling uuids. NOTE: The code for that blueprint is now abandoned, but Mark said he will restore it.
  • List attributes are always a bit tricky for API users (when you do a PUT you replace the whole list, so you need to do a GET first). I'm not saying we should not have them, but if we have an easy alternative, there's probably a point to choose the alternative.
  • On a slightly unrelated note, when we do apply NAT to interface different from the gateway, does it make sense binding it to ports? Or is the concept more similar to the 'extraroute' extension? In that case you would have a list of SNAT/DNAT rules which apply to the router as a whole.

"nati-ueno"

Thank you for your reply. I agree with your points. so how we can support more advanced SNAT/DNAT configuration? Now, we have two options.

[Option1] attribute on router port ( with Marks patch )

   enable_snat
   enable_dnat

[Option2] SNAT/DNAT list

On the iptables we can combine source ip / dest ip / source port/ dest port with protocol with SNAT/DNAT. However this may be too mach for tenant facing apis. if we can use floating ip for each port, I'm +1 for Option1.