yahoo-eng-team team mailing list archive

[Yang Youseok <1846285@xxxxxxxxxxxxxxxxxx>]

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