[openstack-dev] [neutron] Extraroute and router extensions
Nachi Ueno
nachi at ntti3.com
Thu Oct 10 17:22:03 UTC 2013
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
2013/10/9 Ronak Shah <ronak.malav.shah at gmail.com>:
> Hi Rudra,
> Please see inline:
>
> Thanks,
> Ronak
>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 9 Oct 2013 18:25:15 +0000
>> From: Rudra Rugge <rrugge at juniper.net>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [neutron] Extraroute and router extensions
>> Message-ID: <172AF81C-43C5-42E1-B389-00AF74003B99 at juniper.net>
>> Content-Type: text/plain; charset="us-ascii"
>>
>>
>> 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.
>
> [RONAK] - Yes, extra-route is actually a router's route as per following
> definition from extraroute_db.py
> class RouterRoute(model_base.BASEV2, models_v2.Route):
> router_id = sa.Column(sa.String(36),
> sa.ForeignKey('routers.id',
> ondelete="CASCADE"),
> primary_key=True)
> If extra-route routes
>>
>> are available in separate container then sharing of such
>> containers across networks is possible.
>
> [RONAK] - Agreed with the idea. Will following work?
> class NetworkRoute(model_base.BASEV2, models_v2.Route):
> network_id = sa.Column(sa.String(36),
> sa.ForeignKey(networks.id',
> ondelete="CASCADE"),
> primary_key=True)
>
>> 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.
>
> [RONAK] - Agreed. From db standpoint, nexthop just a 64 byte string. But in
> extraroute_db.py there is a restriction of nexthop be only CIDR which should
> be relaxed. Also, I feel taking out this restriction would mean that you
> could assign a static route with a nexthop prior to an incarnation of the
> nexthop (ie. VM instance, host interface etc).
>
>>
>> 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.
>
> [RONAK] - What changes do you have in mind?
>
>> Thanks,
>> Rudra
>>
>>
>>
>>
>> ------------------------------
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list