Public bug reported:
Hi.
I want to discuss further extension about routed network, and wonder how
community think about it.
>From current understanding, routed network is to restrict L2 domain for
specific segment which is usually at the rack level.
I think by expanding the idea that restrict L2 domain further, routed
network would be more generic solution. My naive idea is that
- Make a segment for each hypervisor.
- Admin does not have to deal with segment API.
- Make new type driver to achieve that.
- Make some change for Neutron agent.
- e.g. Distributed DHCP
- e.g. Metadata proxy at DHCP
- e.g. Simplified DVR L3 agent
- Add kernel static host route(/32) in integration bridge and enable proxy arp
to route the VM.
- We have a several routing in the hypervisor.
- Make new L2 extension to achieve that.
- (Optional) Make new BGP agent to propagate kernel static routing to underlay
ToR using iBGP
- It's to automate underlay network
- Neutron does not touch ToR. ToR BGP peer should be pre-defined by admin
- (Optional/Future) Support tenant network to use this concept.
- It's also original future work for the routed network.
- It can be more simplified in this concept since it does not care about
segment anymore.
The gain is by this
- Admin does not care about segment concept.
- Network model is simplified. No concern about VM migration.
- Simplified L3 agent. L3 agent in this model should provide specified
features(DNAT...). Major features of L3 agent to achieve L3 connectivities
could be deleted.
- Achieve tenant network without major change.
- Truly scaled. One giant network could have over million numbers of ports.
For implementation, I think it's not very easy though, Neutron already has
enough blocks to implement. For me, biggest concern is wether having a lot of
segments(same as VM counts) in the networks would be problem or not.
We actually had maintained this architecture for several years, and it's quite
stable. However
it's built in our in-house there would be several defects caused by not
developing with community. So I want to make our system more generic which
implemented at upstream.
Any comments will be appreciated.
Thanks.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1846285
Title:
[RFE] routed network for hypervisor
Status in neutron:
New
Bug description:
Hi.
I want to discuss further extension about routed network, and wonder
how community think about it.
From current understanding, routed network is to restrict L2 domain
for specific segment which is usually at the rack level.
I think by expanding the idea that restrict L2 domain further, routed
network would be more generic solution. My naive idea is that
- Make a segment for each hypervisor.
- Admin does not have to deal with segment API.
- Make new type driver to achieve that.
- Make some change for Neutron agent.
- e.g. Distributed DHCP
- e.g. Metadata proxy at DHCP
- e.g. Simplified DVR L3 agent
- Add kernel static host route(/32) in integration bridge and enable proxy
arp to route the VM.
- We have a several routing in the hypervisor.
- Make new L2 extension to achieve that.
- (Optional) Make new BGP agent to propagate kernel static routing to
underlay ToR using iBGP
- It's to automate underlay network
- Neutron does not touch ToR. ToR BGP peer should be pre-defined by admin
- (Optional/Future) Support tenant network to use this concept.
- It's also original future work for the routed network.
- It can be more simplified in this concept since it does not care about
segment anymore.
The gain is by this
- Admin does not care about segment concept.
- Network model is simplified. No concern about VM migration.
- Simplified L3 agent. L3 agent in this model should provide specified
features(DNAT...). Major features of L3 agent to achieve L3 connectivities
could be deleted.
- Achieve tenant network without major change.
- Truly scaled. One giant network could have over million numbers of ports.
For implementation, I think it's not very easy though, Neutron already has
enough blocks to implement. For me, biggest concern is wether having a lot of
segments(same as VM counts) in the networks would be problem or not.
We actually had maintained this architecture for several years, and it's
quite stable. However
it's built in our in-house there would be several defects caused by not
developing with community. So I want to make our system more generic which
implemented at upstream.
Any comments will be appreciated.
Thanks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1846285/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
