<p><br>
Hi Rudra,</p>
<p>Some comments inline.</p>
<p>Regards,<br>
Salvatore</p>
<p>Il 09/ott/2013 19:27 "Rudra Rugge" <<a href="mailto:rrugge@juniper.net">rrugge@juniper.net</a>> ha scritto:<br>
><br>
> Updated the subject [neutron]<br>
><br>
> Hi All,<br>
><br>
> Is the extra route extension always tied to the router extension or<br>
> can it live in a separate route-table container. If extra-route routes<br>
> are available in separate container then sharing of such<br>
> containers across networks is possible.</p>
<p>At this stage it is just an attribute of the router resource even if they're then implemented in their own database model. Making them reusable across routers (or networks as you suggest) is feasible, provided that we also have a solution to ensure backwards compatibility.</p>

<p>><br>
> Another reason to remove the dependency would be to have<br>
> next hops that are not CIDRs. Next-hops should be allowed as<br>
> interface or a VM instance such as NAT instance. This would<br>
> make the extra route extension more generic.</p>
<p>It should not be excessively hard generalizing the nexthop attribute without breaking compatibility. I reckon this can be done independently from splitting extra routes into a first level resource.<br>
><br>
> This way an extra-route container can be attached/bound to<br>
> either a router extension or to a network as well. Many plugins<br>
> do not need a separate router entity for most of the inter-network<br>
> routing.</p>
<p>Indeed. As you surely are already aware, the subnet resource has a similar attribute for routes to be distributed to instances via DHCP.<br>
><br>
> Thanks,<br>
> Rudra<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>