Re: [openstack-dev] [Neutron] Extraroute and router extensions
Hi Artem Thank you for your pointing out this. I'm still thinking about the design. Once I got the draft, I'll share it in the bp and here.. Best Nachi 2013/10/10 Artem Dmytrenko nexton...@yahoo.com: Hi Rudra, Nachi. Glad to see this discussion on the mailing list! The ExtraRoute routes are fairly limited and it would be great to be able to store more complete routing information in Neutron. I've submitted a blueprint proposing expanding ExtraRoute parameters to include more information (extended-route-params). But it still has a problem where routes are stored in a list and are not indexed. So an update could be painful. Could you share what attributes would you like to see in your RIB API? Thanks! Artem P.S. I'm OpenStack newbie, looking forward to learning from and working with you! Hi Rudra ExtraRoute bp was designed for adding some extra routing for the router. The spec is very handy for simple and small use cases. However it won't fit large use cases, because it takes all route in a Json List. # It means we need to send full route for updating. As Salvatore suggests, we need to keep backward compatibility. so, IMO, we should create Routing table extension. I'm thinking about this in the context of L3VPN (MPLS) extension. My Idea is to have a RIB API in the Neutron. For vpnv4 routes it may have RT or RDs. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Extraroute and router extensions
Great! Looking forward to seeing more of this discussion. I've mentioned that I submitted a blueprint request extending ExtraRoute extension to include more routing attributes. It's located here: https://blueprints.launchpad.net/neutron/+spec/extended-route-params/ and it contains editable google doc. I don't know if it is of much use as it talks heavily about extra route extension. Please feel free to copy any part if you would find it useful (e.g. screenshot) or if you would appreciate any help with your blueprint I'd be very glad to pitch in. Have a good weekend. Sincerely, Artem Dmytrenko On Friday, October 11, 2013 3:02 PM, Nachi Ueno na...@ntti3.com wrote: Hi Artem Thank you for your pointing out this. I'm still thinking about the design. Once I got the draft, I'll share it in the bp and here.. Best Nachi 2013/10/10 Artem Dmytrenko nexton...@yahoo.com: Hi Rudra, Nachi. Glad to see this discussion on the mailing list! The ExtraRoute routes are fairly limited and it would be great to be able to store more complete routing information in Neutron. I've submitted a blueprint proposing expanding ExtraRoute parameters to include more information (extended-route-params). But it still has a problem where routes are stored in a list and are not indexed. So an update could be painful. Could you share what attributes would you like to see in your RIB API? Thanks! Artem P.S. I'm OpenStack newbie, looking forward to learning from and working with you! Hi Rudra ExtraRoute bp was designed for adding some extra routing for the router. The spec is very handy for simple and small use cases. However it won't fit large use cases, because it takes all route in a Json List. # It means we need to send full route for updating. As Salvatore suggests, we need to keep backward compatibility. so, IMO, we should create Routing table extension. I'm thinking about this in the context of L3VPN (MPLS) extension. My Idea is to have a RIB API in the Neutron. For vpnv4 routes it may have RT or RDs. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Extraroute and router extensions
Updated the subject [neutron] Hi All, Is the extra route extension always tied to the router extension or can it live in a separate route-table container. If extra-route routes are available in separate container then sharing of such containers across networks is possible. Another reason to remove the dependency would be to have next hops that are not CIDRs. Next-hops should be allowed as interface or a VM instance such as NAT instance. This would make the extra route extension more generic. This way an extra-route container can be attached/bound to either a router extension or to a network as well. Many plugins do not need a separate router entity for most of the inter-network routing. Thanks, Rudra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Extraroute and router extensions
Hi Rudra, Some comments inline. Regards, Salvatore Il 09/ott/2013 19:27 Rudra Rugge rru...@juniper.net ha scritto: Updated the subject [neutron] Hi All, Is the extra route extension always tied to the router extension or can it live in a separate route-table container. If extra-route routes are available in separate container then sharing of such containers across networks is possible. 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. Another reason to remove the dependency would be to have next hops that are not CIDRs. Next-hops should be allowed as interface or a VM instance such as NAT instance. This would make the extra route extension more generic. 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. This way an extra-route container can be attached/bound to either a router extension or to a network as well. Many plugins do not need a separate router entity for most of the inter-network routing. Indeed. As you surely are already aware, the subnet resource has a similar attribute for routes to be distributed to instances via DHCP. Thanks, Rudra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
