)]}'
{"specs/liberty/address-scopes.rst":[{"author":{"_account_id":8124,"name":"cbrandily","email":"zzelle@gmail.com","username":"cbrandily"},"change_message_id":"4eef3ac62739028eaab3989fb71263cbdf4d82f3","unresolved":false,"context_lines":[{"line_number":16,"context_line":"be used by Neutron to address this problem."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9af37de9_f849c58f","line":19,"updated":"2015-05-10 11:43:32.000000000","message":"\"subnet topology\" perhaps?","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"ae4afb24e22196f856dff9a52273a039fa5c42fd","unresolved":false,"context_lines":[{"line_number":16,"context_line":"be used by Neutron to address this problem."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_87549a54","line":19,"in_reply_to":"5ad58531_13eeb4ec","updated":"2015-05-11 22:35:26.000000000","message":"Some of these are good suggestions.  I think we should ask after summit.  \"Address scopes\" has already gotten some traction.  I\u0027d hate to change it to something else and have people wondering what we\u0027re talking about.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"f3a52db23fc395d98eafbb4cfb76161ff531f564","unresolved":false,"context_lines":[{"line_number":16,"context_line":"be used by Neutron to address this problem."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_13eeb4ec","line":19,"in_reply_to":"5ad58531_304be65b","updated":"2015-05-11 20:19:01.000000000","message":"What about:\n\nL3 Address Space\n\nL3 Area\n\nRouting Area (maybe evokes OSPF too much)\n\nRouting Space\n\nRouting Domain","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"8cb72861b550a02584c9afff6efea29aaa4e3706","unresolved":false,"context_lines":[{"line_number":16,"context_line":"be used by Neutron to address this problem."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_304be65b","line":19,"in_reply_to":"7ad8896b_c2c972ae","updated":"2015-05-11 19:53:12.000000000","message":"+1 Address \"Realm\"","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"0fbbe3d8b46cf384a6b08a452eaa8c664402cdbd","unresolved":false,"context_lines":[{"line_number":16,"context_line":"be used by Neutron to address this problem."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7ad8896b_c2c972ae","line":19,"in_reply_to":"9af37de9_f849c58f","updated":"2015-05-11 18:51:15.000000000","message":"To me, topology describes how things are laid out or arranged.  It doesn\u0027t seem to say that there are multiple isolated scopes.\n\nBelow are some words that I\u0027ve come up with.  I don\u0027t personally like any of them better than scope.  But, I\u0027ll list them to get more feedback.\n\nRealm\nSpan\nDomain","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"db2f1e238f0663c6ba7bcc43333351162080eb4f","unresolved":false,"context_lines":[{"line_number":83,"context_line":"   addresses can\u0027t be used to distiguish the address scope because they may"},{"line_number":84,"context_line":"   have nothing to do with the subnets on the link; they may have been"},{"line_number":85,"context_line":"   forwarded to/from somewhere else.  The incoming interface can\u0027t be used"},{"line_number":86,"context_line":"   because it is ambiguous."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Subnets on a network will be constrained to the same address scope [#]_."},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_a2281ee3","line":86,"updated":"2015-05-05 19:47:00.000000000","message":"Are we painting ourselves into a corner by not allowing multiple scopes on the same network?  This might be a reasonable constraint on the first pass in Liberty.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"0fbbe3d8b46cf384a6b08a452eaa8c664402cdbd","unresolved":false,"context_lines":[{"line_number":83,"context_line":"   addresses can\u0027t be used to distiguish the address scope because they may"},{"line_number":84,"context_line":"   have nothing to do with the subnets on the link; they may have been"},{"line_number":85,"context_line":"   forwarded to/from somewhere else.  The incoming interface can\u0027t be used"},{"line_number":86,"context_line":"   because it is ambiguous."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Subnets on a network will be constrained to the same address scope [#]_."},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9af37de9_0fb0a6dc","line":86,"in_reply_to":"3acd31a7_a2281ee3","updated":"2015-05-11 18:51:15.000000000","message":"My only concerns are existing deployments that have networks from different pools (or no pool if that\u0027s the way you want to think about it) and changing scopes discussed below (L94).","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"db2f1e238f0663c6ba7bcc43333351162080eb4f","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":".. TODO Would it be better to constrain them to the same pool?  It could get"},{"line_number":93,"context_line":"   really complicated when pools can be associated with different scopes.  What"},{"line_number":94,"context_line":"   if a pool changes scope and this leaves some networks with mixed scopes?"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Data Model Impact"},{"line_number":97,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_c2a79a09","line":94,"updated":"2015-05-05 19:47:00.000000000","message":"Are you thinking subnet pools could be moved between scopes?  What\u0027s the use case you have in mind for that? I think we could save ourselves some headache by not letting subnet pools float between scopes.  I suppose one interesting use case might be migrating tenants from one scope to another. By moving the associated subnet pools you\u0027ve now migrated everything between scopes.  Not sure how compelling of a use case that is though. Thoughts?","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"0fbbe3d8b46cf384a6b08a452eaa8c664402cdbd","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":".. TODO Would it be better to constrain them to the same pool?  It could get"},{"line_number":93,"context_line":"   really complicated when pools can be associated with different scopes.  What"},{"line_number":94,"context_line":"   if a pool changes scope and this leaves some networks with mixed scopes?"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Data Model Impact"},{"line_number":97,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9af37de9_cf417e3b","line":94,"in_reply_to":"3acd31a7_c2a79a09","updated":"2015-05-11 18:51:15.000000000","message":"The use case that I see for moving subnet pools between scopes is to consolidate scopes.  For example, say a tenant has some global addresses and sets up a pool with them before talking to the operator of the cloud.  Then, they go to the operator to consolidate them into the global scope.  Also, I imagine there may me pools that exist before upgrading to Liberty and then the operators want to put them in to an address pool after the upgrade.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"f3a52db23fc395d98eafbb4cfb76161ff531f564","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":".. TODO Would it be better to constrain them to the same pool?  It could get"},{"line_number":93,"context_line":"   really complicated when pools can be associated with different scopes.  What"},{"line_number":94,"context_line":"   if a pool changes scope and this leaves some networks with mixed scopes?"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Data Model Impact"},{"line_number":97,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_733f3826","line":94,"in_reply_to":"5ad58531_3049a6d1","updated":"2015-05-11 20:19:01.000000000","message":"Yeah, I think you would block the consolidation of scopes with overlapping pools. I would think the consolidation could be an add on feature, as long as we support routing between scopes via NAT. The consolidation feature would eliminate the need for NAT in that case for better performance, but functionally they would be equivalent.\n\nSpeaking of NAT, how will that work between scopes? Would that be a static NAT? How do floating IPs figure in? It\u0027s not really addressed here. Presumable floating IPs are just a special case of NAT between scopes.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"e2b2848efd71c656af2372b823d78555dd3c81f0","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":".. TODO Would it be better to constrain them to the same pool?  It could get"},{"line_number":93,"context_line":"   really complicated when pools can be associated with different scopes.  What"},{"line_number":94,"context_line":"   if a pool changes scope and this leaves some networks with mixed scopes?"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Data Model Impact"},{"line_number":97,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_73dbb8ee","line":94,"in_reply_to":"5ad58531_3049a6d1","updated":"2015-05-11 20:35:31.000000000","message":"Yes, I think subnet pools should only be consolidated if they have non-overlapping IPs.  This could get a bit tricky.  This also implies that growing a subnet pool should check all other pools in the scope.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"ae4afb24e22196f856dff9a52273a039fa5c42fd","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":".. TODO Would it be better to constrain them to the same pool?  It could get"},{"line_number":93,"context_line":"   really complicated when pools can be associated with different scopes.  What"},{"line_number":94,"context_line":"   if a pool changes scope and this leaves some networks with mixed scopes?"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Data Model Impact"},{"line_number":97,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_271de6bd","line":94,"in_reply_to":"5ad58531_73dbb8ee","updated":"2015-05-11 22:35:26.000000000","message":"@John, great question!  I had an answer to this that I failed to include in this document.  I had forgotten that the detail needed explicit attention.\n\nNAT will be automatically included between any ipv4 scope and an ipv4 \"external\" network to which a router is connected as a gateway.  It will provide 1-1 NAT for floating IPs and many-1 for default SNAT.  This will support existing use cases.  I don\u0027t intend to provide any more than this at this time.  I think an addition (post-Liberty) may be a more general ipv4 NAT functionality but I want to gauge the demand for that and explore other options too, like providing something as part of LBaaS or something like that.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"8cb72861b550a02584c9afff6efea29aaa4e3706","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":".. TODO Would it be better to constrain them to the same pool?  It could get"},{"line_number":93,"context_line":"   really complicated when pools can be associated with different scopes.  What"},{"line_number":94,"context_line":"   if a pool changes scope and this leaves some networks with mixed scopes?"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Data Model Impact"},{"line_number":97,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_3049a6d1","line":94,"in_reply_to":"9af37de9_cf417e3b","updated":"2015-05-11 19:53:12.000000000","message":"I think the consolidation of scopes is a reasonable use case. One example of a tricky scenario is if the subnet pool being migrated contains prefixes that have been allocated in both scopes, what do you do? Do you block the user from moving the pool between scopes? Some things to think through.  However, as I think about it I don\u0027t see anything that\u0027s a show-stopper for supporting this use case in some fashion.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"db2f1e238f0663c6ba7bcc43333351162080eb4f","unresolved":false,"context_lines":[{"line_number":143,"context_line":"shouldn\u0027t have any bigger impact than deploying a software upgrade which would"},{"line_number":144,"context_line":"restart L3 agents."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":".. TODO consider making address scopes admin-only?"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"When an L3 agent requests information about a router, the address scope of each"},{"line_number":149,"context_line":"of the subnets to which the router is connected must be looked up.  This can be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_d79cfa0f","line":146,"updated":"2015-05-05 19:47:00.000000000","message":"What\u0027s the drawback of letting tenants create their own address scopes?  I\u0027m not sure we want to block that by making address scope create/update/delete admin-only.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"e2b2848efd71c656af2372b823d78555dd3c81f0","unresolved":false,"context_lines":[{"line_number":143,"context_line":"shouldn\u0027t have any bigger impact than deploying a software upgrade which would"},{"line_number":144,"context_line":"restart L3 agents."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":".. TODO consider making address scopes admin-only?"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"When an L3 agent requests information about a router, the address scope of each"},{"line_number":149,"context_line":"of the subnets to which the router is connected must be looked up.  This can be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_53ff9c34","line":146,"in_reply_to":"3acd31a7_d79cfa0f","updated":"2015-05-11 20:35:31.000000000","message":"None, in fact my use case above (L95) implies that tenants can create them before going to the operator to have them included in a scope.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"db2f1e238f0663c6ba7bcc43333351162080eb4f","unresolved":false,"context_lines":[{"line_number":158,"context_line":"they\u0027re missing the point because this isn\u0027t just about solving the problem of"},{"line_number":159,"context_line":"overlapping IPv4 addresses.  It also recognizes that we have tenants choosing"},{"line_number":160,"context_line":"IPv6 addresses too.  They could overlap or not be routable for other reasons."},{"line_number":161,"context_line":"We\u0027re giving Neutron the ability to know how to handle them."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"Other Deployer Impact"},{"line_number":164,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_626a0683","line":161,"updated":"2015-05-05 19:47:00.000000000","message":"+1. A lot the workloads in the cloud are for test/dev purposes. Being able to carve out an IPv6 environment that isn\u0027t REALLY globally routable could come in handy.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"e2b2848efd71c656af2372b823d78555dd3c81f0","unresolved":false,"context_lines":[{"line_number":158,"context_line":"they\u0027re missing the point because this isn\u0027t just about solving the problem of"},{"line_number":159,"context_line":"overlapping IPv4 addresses.  It also recognizes that we have tenants choosing"},{"line_number":160,"context_line":"IPv6 addresses too.  They could overlap or not be routable for other reasons."},{"line_number":161,"context_line":"We\u0027re giving Neutron the ability to know how to handle them."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"Other Deployer Impact"},{"line_number":164,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_b6dc6e47","line":161,"in_reply_to":"3acd31a7_626a0683","updated":"2015-05-11 20:35:31.000000000","message":"+1  I\u0027m sure this will happen all the time in various ways.","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"db2f1e238f0663c6ba7bcc43333351162080eb4f","unresolved":false,"context_lines":[{"line_number":206,"context_line":"  `carl-baldwin \u003chttps://launchpad.net/~carl-baldwin\u003e`_"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"Other contributors:"},{"line_number":209,"context_line":"  Volunteers?"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Work Items"},{"line_number":212,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_82f882c4","line":209,"updated":"2015-05-05 19:47:00.000000000","message":"Me","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"e2b2848efd71c656af2372b823d78555dd3c81f0","unresolved":false,"context_lines":[{"line_number":206,"context_line":"  `carl-baldwin \u003chttps://launchpad.net/~carl-baldwin\u003e`_"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"Other contributors:"},{"line_number":209,"context_line":"  Volunteers?"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Work Items"},{"line_number":212,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_535b1c55","line":209,"in_reply_to":"3acd31a7_82f882c4","updated":"2015-05-11 20:35:31.000000000","message":"Done","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"f3a52db23fc395d98eafbb4cfb76161ff531f564","unresolved":false,"context_lines":[{"line_number":206,"context_line":"  `carl-baldwin \u003chttps://launchpad.net/~carl-baldwin\u003e`_"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"Other contributors:"},{"line_number":209,"context_line":"  Volunteers?"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Work Items"},{"line_number":212,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_5351dc61","line":209,"in_reply_to":"3acd31a7_82f882c4","updated":"2015-05-11 20:19:01.000000000","message":"Me too","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"ae4afb24e22196f856dff9a52273a039fa5c42fd","unresolved":false,"context_lines":[{"line_number":206,"context_line":"  `carl-baldwin \u003chttps://launchpad.net/~carl-baldwin\u003e`_"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"Other contributors:"},{"line_number":209,"context_line":"  Volunteers?"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Work Items"},{"line_number":212,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_274ba6b2","line":209,"in_reply_to":"5ad58531_5351dc61","updated":"2015-05-11 22:35:26.000000000","message":"Done","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":14605,"name":"vikram.choudhary","email":"vikschw@gmail.com","username":"vikram.choudhary"},"change_message_id":"2ed7d6beaef03399a26ceb169b89e7332a37171a","unresolved":false,"context_lines":[{"line_number":207,"context_line":""},{"line_number":208,"context_line":"Other contributors:"},{"line_number":209,"context_line":"  Volunteers?"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Work Items"},{"line_number":212,"context_line":"----------"},{"line_number":213,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1aca2d91_89b5a032","line":210,"updated":"2015-05-07 15:20:16.000000000","message":"Would like to contribute:)","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"e2b2848efd71c656af2372b823d78555dd3c81f0","unresolved":false,"context_lines":[{"line_number":207,"context_line":""},{"line_number":208,"context_line":"Other contributors:"},{"line_number":209,"context_line":"  Volunteers?"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Work Items"},{"line_number":212,"context_line":"----------"},{"line_number":213,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ad58531_33589056","line":210,"in_reply_to":"1aca2d91_89b5a032","updated":"2015-05-11 20:35:31.000000000","message":"Done","commit_id":"33e0f2117cdd5037f338c6acd718ad9dba5e4c84"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"757f5ba9d7642219ae842bcc2a8e3562d2b7c129","unresolved":false,"context_lines":[{"line_number":76,"context_line":"implementation will use multiple routing tables and policy routing to"},{"line_number":77,"context_line":"implement connecting to networks with different address scopes.  Both"},{"line_number":78,"context_line":"the incoming device (iif) and the subnet prefix will be specified with"},{"line_number":79,"context_line":"each rule."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":".. TODO What happens if there are multiple subnets on a network from different"},{"line_number":82,"context_line":"   address scopes.  This can happen today.  The source and destination"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ad58531_5348bc2d","line":79,"updated":"2015-05-11 20:09:24.000000000","message":"It seems to me that by definition IPv4 and IPv6 prefixes don\u0027t share scope. As such, do we want to make address scopes unique on address family? Maybe I missed this discussion.","commit_id":"fd0255ca55f8da6d8527f3f5b7adc00531f59478"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"757f5ba9d7642219ae842bcc2a8e3562d2b7c129","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":".. TODO Would it be better to constrain them to the same pool?  It could get"},{"line_number":93,"context_line":"   really complicated when pools can be associated with different scopes.  What"},{"line_number":94,"context_line":"   if a pool changes scope and this leaves some networks with mixed scopes?"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Data Model Impact"},{"line_number":97,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ad58531_7320584a","line":94,"updated":"2015-05-11 20:09:24.000000000","message":"If I can get https://review.openstack.org//#/c/180299/ merged, I think this is a reasonable constraint.","commit_id":"fd0255ca55f8da6d8527f3f5b7adc00531f59478"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"40c947db2d2b7ec447303c3b71ee2e7bfe13e6e7","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":".. TODO Would it be better to constrain them to the same pool?  It could get"},{"line_number":93,"context_line":"   really complicated when pools can be associated with different scopes.  What"},{"line_number":94,"context_line":"   if a pool changes scope and this leaves some networks with mixed scopes?"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Data Model Impact"},{"line_number":97,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ad58531_56ac2aed","line":94,"in_reply_to":"5ad58531_7320584a","updated":"2015-05-11 20:35:26.000000000","message":"Gerrit is hiding that one from me today.  However, I think I know which one that is.","commit_id":"fd0255ca55f8da6d8527f3f5b7adc00531f59478"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"757f5ba9d7642219ae842bcc2a8e3562d2b7c129","unresolved":false,"context_lines":[{"line_number":143,"context_line":"shouldn\u0027t have any bigger impact than deploying a software upgrade which would"},{"line_number":144,"context_line":"restart L3 agents."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":".. TODO consider making address scopes admin-only?"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"When an L3 agent requests information about a router, the address scope of each"},{"line_number":149,"context_line":"of the subnets to which the router is connected must be looked up.  This can be"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ad58531_b00b567d","line":146,"updated":"2015-05-11 20:09:24.000000000","message":"See comments on PS2","commit_id":"fd0255ca55f8da6d8527f3f5b7adc00531f59478"},{"author":{"_account_id":6524,"name":"Henry Gessau","email":"HenryG@gessau.net","username":"gessau"},"change_message_id":"2e003f72cf839dfc895ad6545b89273a17f2285b","unresolved":false,"context_lines":[{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a0c5dc1_30764e3f","line":20,"updated":"2015-05-12 03:25:55.000000000","message":"This seems a lot like VRFs to me. And I just came across this: https://lwn.net/Articles/632522/","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"c508677465d0b634170b0241302eb687022a64dc","unresolved":false,"context_lines":[{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a0c5dc1_e2969993","line":20,"in_reply_to":"9a0c5dc1_30764e3f","updated":"2015-05-12 13:41:59.000000000","message":"It\u0027s something like VRF, except in network gear each VRF is only locally defined. This concept is a bit more like an L3 VPN or a route target in that it defines a consistent routing domain across multiple devices.\n\nThe kernel link is interesting. In other contexts we have just use multiple routing tables in Linux with virtual interfaces (.1q in our case) tied to each routing table. This scales pretty well. The biggest issue we had is that most linux utilities use source IP to select the outbound interface. This forced a constraint where a given host could not have the same IP in different VRFs because. The RFC here would eliminate that problem.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"d2594118e244b90f4fb66d53725eea76d8072a7e","unresolved":false,"context_lines":[{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a0c5dc1_ddbec7fe","line":20,"in_reply_to":"9a0c5dc1_d7c46841","updated":"2015-05-12 18:06:55.000000000","message":"From the link Henry shared (btw thanks @Henry):\n\n\"The intent of VRFs is to provide an additional, logical separation at the L3 layer within a namespace\"\n\nI don\u0027t necessarily see any overlap or conflict. I don\u0027t see VRF\u0027s as displacing or being incompatible with anything we have today in Neutron.  I\u0027m starting to think of address scopes in much the same way as IP namespaces.  We might have VRF\u0027s hosted under the umbrella of an address scope. In that sense with the analogy of address scope to linux namespace, I see VRF\u0027s as a little bit of a tangent to this spec. Thoughts?\n\nSince you\u0027re looking for suggestions, maybe something along the lines of \"IP/routing namespace\" is a more appropriate term than address scopes?","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"9fd30d3f84e7691f9c9976237bc3ef573603844f","unresolved":false,"context_lines":[{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a0c5dc1_32ed128c","line":20,"in_reply_to":"9a0c5dc1_d7c46841","updated":"2015-05-12 17:55:53.000000000","message":"I am not sure it\u0027s relevant to Neutron. In our case, we had a lot of existing code using existing libraries and we were integrating VRF support. We had libraries that we could pass the source IP to but not the source interface. We had a routing table per VRF. If we had two interfaces with the same IP (in different VRFs), we could not deterministically pick an interface, and so we couldn\u0027t pick a routing table/VRF.\n\nFor example, looking at the ssh man page, you can specify -b to select the bind address. But if two interfaces have that address you are out of luck. \n\nNamespaces solve this but multiple routing tables do not. \n\nThat said, this is not necessarily an issue if your underlying libraries allow you to lock down a specific interface.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"73782fb55b1e28711509a45b18747dcdec23ce24","unresolved":false,"context_lines":[{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a0c5dc1_f83759e1","line":20,"in_reply_to":"9a0c5dc1_ddbec7fe","updated":"2015-05-12 20:24:21.000000000","message":"@Ryan Thanks for the clarification.  I glanced over it and did not understand a few things.  I\u0027ve read a little deeper in to it.  The fact remains that this is still in the design and feedback stages.  It will be a while before it is available to us.\n\n@John  Thanks, I see the problem.  It seems there is not a way to get a local process to initiate connections that are routed with a particular routing table.  This could be a problem in a few cases, mostly when operators are diagnosing, or developers are fiddling around and jump in to a namespace to ping, ssh, or otherwise to another address on an internal network.\n\nIt might take a little work to get something like the metadata server working correctly too.  This is good food for thought.  Maybe we need a utility to select which routing table local processes go to by setting the policy for when iif is lo.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"eec9375833bd880b5b5598ca35d95ef840b0a694","unresolved":false,"context_lines":[{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a0c5dc1_d7c46841","line":20,"in_reply_to":"9a0c5dc1_e2969993","updated":"2015-05-12 17:25:16.000000000","message":"It certainly is not an accident that this sounds like VRF and L3 VPN.  Both were considered in writing this document.  My hope is to align this with L3 VPN so that we can bring in L3 VPNs in to Neutron and handle them appropriately, something which has been requested a lot.\n\nThe VRF link is interesting but it looks to me like a very recent work in progress (i.e. introduced this year).  It may take a while for this work to trickle in to all the distributions and kernels to be deployed.\n\nIt also looks like VRFs either overlap or conflict with namespaces.  It could be difficult to work this in with the current L3 implementation.  Multiple routing tables appears to work correctly with namespaces in the testing and experimentation that I\u0027ve done.\n\n@John I\u0027m not sure what you mean about using \"source IP to select the outbound interface\"  Could you elaborate?  There are some details about multiple routing tables and policy routing that I don\u0027t grasp yet so please educate me.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":14605,"name":"vikram.choudhary","email":"vikschw@gmail.com","username":"vikram.choudhary"},"change_message_id":"0607a82192fb0c3c716e5133ea42b27b34d10381","unresolved":false,"context_lines":[{"line_number":49,"context_line":"Also, the full integration of MPLS/BGP VPN in to Neutron has been blocked by"},{"line_number":50,"context_line":"this.  An analog to address scopes in the L3 VPN world are route"},{"line_number":51,"context_line":"distinguishers.  With the addition of address scopes, we can easily map to"},{"line_number":52,"context_line":"route distinguishers.  This work is not in scope for this blueprint but will be"},{"line_number":53,"context_line":"further enabled by it."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/subnet-allocation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a0c5dc1_969df25b","line":52,"updated":"2015-05-12 05:25:06.000000000","message":"I am little curious about how this proposal can address route distinguisher functionality. Could you please throw some light achieving this use case?","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"c508677465d0b634170b0241302eb687022a64dc","unresolved":false,"context_lines":[{"line_number":49,"context_line":"Also, the full integration of MPLS/BGP VPN in to Neutron has been blocked by"},{"line_number":50,"context_line":"this.  An analog to address scopes in the L3 VPN world are route"},{"line_number":51,"context_line":"distinguishers.  With the addition of address scopes, we can easily map to"},{"line_number":52,"context_line":"route distinguishers.  This work is not in scope for this blueprint but will be"},{"line_number":53,"context_line":"further enabled by it."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/subnet-allocation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a0c5dc1_82e47d3b","line":52,"in_reply_to":"9a0c5dc1_969df25b","updated":"2015-05-12 13:41:59.000000000","message":"You tie an RD to the local routing table in a given router, and then each address scope corresponds to a route target advertised in BGP.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":6659,"name":"Paul Michali","email":"pc@michali.net","username":"pcm"},"change_message_id":"5fe19db22186743f1d9535ade03efca9ee185c3a","unresolved":false,"context_lines":[{"line_number":60,"context_line":"Add a new object called AddressScope.  An AddressScope can be associated with"},{"line_number":61,"context_line":"multiple SubnetPool objects in a one-to-many relationship.  This will allow"},{"line_number":62,"context_line":"delegating parts of an address scope to different tenants.  The SubnetPools"},{"line_number":63,"context_line":"under an AddressScope must not overlap.  They must also be from the same"},{"line_number":64,"context_line":"address family.  Only an admin can associate an AddressPool and SubnetPool from"},{"line_number":65,"context_line":"different tenants."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_2b77b6a0","line":63,"updated":"2015-05-27 14:01:47.000000000","message":"Does the AddressScope also ensure that the subnets contained within are routable/valid subnets?  How does it do that?","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"2c8ae24290596c1b3fa218699aec6f9147a08a5e","unresolved":false,"context_lines":[{"line_number":60,"context_line":"Add a new object called AddressScope.  An AddressScope can be associated with"},{"line_number":61,"context_line":"multiple SubnetPool objects in a one-to-many relationship.  This will allow"},{"line_number":62,"context_line":"delegating parts of an address scope to different tenants.  The SubnetPools"},{"line_number":63,"context_line":"under an AddressScope must not overlap.  They must also be from the same"},{"line_number":64,"context_line":"address family.  Only an admin can associate an AddressPool and SubnetPool from"},{"line_number":65,"context_line":"different tenants."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_8dd10cfe","line":63,"in_reply_to":"7a016987_2b77b6a0","updated":"2015-05-27 21:43:30.000000000","message":"I could envision create_subnetpool() and update_subnetpool() using the AdressScope UUID to look across all subnetpools in the address scope to enforce uniqueness of a prefix.  Even though AdressScopes are more than a grouping mechanism, the address scope would be used as a sort of grouping mechanism in this particular case.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"d45bfb2d86edf5e8252eef780c63a2709bd76a31","unresolved":false,"context_lines":[{"line_number":60,"context_line":"Add a new object called AddressScope.  An AddressScope can be associated with"},{"line_number":61,"context_line":"multiple SubnetPool objects in a one-to-many relationship.  This will allow"},{"line_number":62,"context_line":"delegating parts of an address scope to different tenants.  The SubnetPools"},{"line_number":63,"context_line":"under an AddressScope must not overlap.  They must also be from the same"},{"line_number":64,"context_line":"address family.  Only an admin can associate an AddressPool and SubnetPool from"},{"line_number":65,"context_line":"different tenants."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_258568ce","line":63,"in_reply_to":"7a016987_8dd10cfe","updated":"2015-05-28 18:26:22.000000000","message":"Yes, it needs to look across subnet pools in the address scope.  This implies some sort of lock on the address scope table while updating subnet pools.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7505,"name":"Jaume Devesa","email":"devvesa@gmail.com","username":"devesa"},"change_message_id":"b2a6f5f630e88328444c7c2529b4460e87646e8a","unresolved":false,"context_lines":[{"line_number":62,"context_line":"delegating parts of an address scope to different tenants.  The SubnetPools"},{"line_number":63,"context_line":"under an AddressScope must not overlap.  They must also be from the same"},{"line_number":64,"context_line":"address family.  Only an admin can associate an AddressPool and SubnetPool from"},{"line_number":65,"context_line":"different tenants."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":68,"context_line":"alone in its own address scope.  The id of the subnet pool will be used as the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_ce439b12","line":65,"updated":"2015-05-27 09:56:19.000000000","message":"Just to confirm: This is for the public routable address scope, right? So you can assign the external SubnetPool and tenants SubnetPools into the same AddressScope and you can guarantee that these tenant networks are internet-routable.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"b580ed9fe98b5d6eb30483fb66f299ed9ff752a5","unresolved":false,"context_lines":[{"line_number":62,"context_line":"delegating parts of an address scope to different tenants.  The SubnetPools"},{"line_number":63,"context_line":"under an AddressScope must not overlap.  They must also be from the same"},{"line_number":64,"context_line":"address family.  Only an admin can associate an AddressPool and SubnetPool from"},{"line_number":65,"context_line":"different tenants."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":68,"context_line":"alone in its own address scope.  The id of the subnet pool will be used as the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_ee7e4c69","line":65,"in_reply_to":"7a016987_ce439b12","updated":"2015-05-27 14:34:30.000000000","message":"s/AddressPool/AddressScope/\n\n@Jaume, my understanding is that you would create a SubnetPool that is tied to an externally routed AddressScope, and then you would assign that to a tenants so they can allocate routable subnets from the pool. I think this is subtly different than your description.\n\nI suppose we could *almost* think of an address scope as a virtual router. I haven\u0027t thought through all the consequences of that, but it may be another way to implement this same concept. (In fact that is how Juniper implements the equivalent of Cisco VRFs if I recall correctly). You could then designate that a given router will advertise all its routes. The router would enforce the uniqueness of address space in the same way we are talking about address scopes doing it. The underlying implementation would probably look the same, but the abstraction would be different.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"d45bfb2d86edf5e8252eef780c63a2709bd76a31","unresolved":false,"context_lines":[{"line_number":62,"context_line":"delegating parts of an address scope to different tenants.  The SubnetPools"},{"line_number":63,"context_line":"under an AddressScope must not overlap.  They must also be from the same"},{"line_number":64,"context_line":"address family.  Only an admin can associate an AddressPool and SubnetPool from"},{"line_number":65,"context_line":"different tenants."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":68,"context_line":"alone in its own address scope.  The id of the subnet pool will be used as the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_8561bc3b","line":65,"in_reply_to":"7a016987_d4e77a3e","updated":"2015-05-28 18:26:22.000000000","message":"Will fix AddressPool.  Silly me.  Done.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7505,"name":"Jaume Devesa","email":"devvesa@gmail.com","username":"devesa"},"change_message_id":"0ce1d63a54f538b021ac535a9b4436f84b74af2b","unresolved":false,"context_lines":[{"line_number":62,"context_line":"delegating parts of an address scope to different tenants.  The SubnetPools"},{"line_number":63,"context_line":"under an AddressScope must not overlap.  They must also be from the same"},{"line_number":64,"context_line":"address family.  Only an admin can associate an AddressPool and SubnetPool from"},{"line_number":65,"context_line":"different tenants."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":68,"context_line":"alone in its own address scope.  The id of the subnet pool will be used as the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_d4e77a3e","line":65,"in_reply_to":"7a016987_ee7e4c69","updated":"2015-05-28 11:37:57.000000000","message":"Ok. I get the difference. Thanks for the clarification, John.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7505,"name":"Jaume Devesa","email":"devvesa@gmail.com","username":"devesa"},"change_message_id":"8a4f6ea23ebad80d412499b1cc2d695cb341cd2d","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":68,"context_line":"alone in its own address scope.  The id of the subnet pool will be used as the"},{"line_number":69,"context_line":"id of the address scope."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_93116ab2","line":69,"updated":"2015-05-27 09:46:05.000000000","message":"When will be used? In the RPC call to configure the routers, you mean? In theory, (and before knowing the answer) since we use \u0027uuid\u0027 in Neutron, the fact that two logical entities share the same \u0027uuid\u0027, it sounds like a violation about what \u0027uuid\u0027 means. It can be confusing when reviewing the code too... \n\nsorry, i don\u0027t have an alternative in mind, though.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"d45bfb2d86edf5e8252eef780c63a2709bd76a31","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":68,"context_line":"alone in its own address scope.  The id of the subnet pool will be used as the"},{"line_number":69,"context_line":"id of the address scope."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_c5a7b44e","line":69,"in_reply_to":"7a016987_93116ab2","updated":"2015-05-28 18:26:22.000000000","message":"Jaume, you make a good point.  I intended for it to be limited to the RPC call from the routers to get router information.  It will be an implementation detail.\n\nWe\u0027ll need to handle subnet pools that are not associated with an address scope somehow because, when we roll this out, all existing subnet pools will be unassociated.\n\nAn alternative is to treat them as part of the \"implicit\" scope until they are associated with an address scope.  Thoughts on that?","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":14605,"name":"vikram.choudhary","email":"vikschw@gmail.com","username":"vikram.choudhary"},"change_message_id":"0607a82192fb0c3c716e5133ea42b27b34d10381","unresolved":false,"context_lines":[{"line_number":69,"context_line":"id of the address scope."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"},{"line_number":73,"context_line":"connecting to networks with different address scopes.  The incoming device"},{"line_number":74,"context_line":"(iif) will be specified with each rule."},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a0c5dc1_d68c8a37","line":72,"updated":"2015-05-12 05:25:06.000000000","message":"Can you please site an example to make things clear? I am confused with multiple routing tables. How neutron router will maintain different routing tables? what will be the key?","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"73782fb55b1e28711509a45b18747dcdec23ce24","unresolved":false,"context_lines":[{"line_number":69,"context_line":"id of the address scope."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"},{"line_number":73,"context_line":"connecting to networks with different address scopes.  The incoming device"},{"line_number":74,"context_line":"(iif) will be specified with each rule."},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a0c5dc1_3814d1f3","line":72,"in_reply_to":"9a0c5dc1_d68c8a37","updated":"2015-05-12 20:24:21.000000000","message":"Sure, the Linux \"ip\" man page [1] is a good reference.  Basically, there is a main routing table, a couple of kernel maintained routing tables, and room for many more independent routing tables.  They are indexed by an integer up to 2^31.  The routing policy database is how to select the correct routing table.\n\n [1] http://linux.die.net/man/8/ip  (Search for routing policy database management)","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"b580ed9fe98b5d6eb30483fb66f299ed9ff752a5","unresolved":false,"context_lines":[{"line_number":81,"context_line":""},{"line_number":82,"context_line":"NAT will be automatically included between any ipv4 scope and an ipv4"},{"line_number":83,"context_line":"\"external\" network to which a router is connected as a gateway.  It will"},{"line_number":84,"context_line":"provide 1-1 NAT for floating IPs and many-1 for default SNAT.  This will"},{"line_number":85,"context_line":"support existing use cases.  I don\u0027t intend to provide any more than this at"},{"line_number":86,"context_line":"this time.  I think an addition (post-Liberty) may be a more general ipv4 NAT"},{"line_number":87,"context_line":"functionality but I want to gauge the demand for that and explore other options"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_0923e2a8","line":84,"updated":"2015-05-27 14:34:30.000000000","message":"I was thinking the way this would work is what I described above. That is, if you attach a tenant subnet pool to an address scope with an external network, then the subnets from that pool will be advertised to the router on the external network. This would be direct without any NAT.\n\nIf on the other hand, you had a tenant *address scope* that was private, and you put attach a subnet associated with that address scope to router that is attached to an external network, we would NAT.\n\nMaybe I am confusing myself here as I am starting to think of address scopes as VRFs (routing table + ARP basically) which is probably not accurate.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"d45bfb2d86edf5e8252eef780c63a2709bd76a31","unresolved":false,"context_lines":[{"line_number":81,"context_line":""},{"line_number":82,"context_line":"NAT will be automatically included between any ipv4 scope and an ipv4"},{"line_number":83,"context_line":"\"external\" network to which a router is connected as a gateway.  It will"},{"line_number":84,"context_line":"provide 1-1 NAT for floating IPs and many-1 for default SNAT.  This will"},{"line_number":85,"context_line":"support existing use cases.  I don\u0027t intend to provide any more than this at"},{"line_number":86,"context_line":"this time.  I think an addition (post-Liberty) may be a more general ipv4 NAT"},{"line_number":87,"context_line":"functionality but I want to gauge the demand for that and explore other options"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_f01ef00a","line":84,"in_reply_to":"7a016987_0923e2a8","updated":"2015-05-28 18:26:22.000000000","message":"@John, you\u0027re right.  This does need a little bit of clarification.  I\u0027m not sure that address scopes are that different from VRFs.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7505,"name":"Jaume Devesa","email":"devvesa@gmail.com","username":"devesa"},"change_message_id":"8a4f6ea23ebad80d412499b1cc2d695cb341cd2d","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Data Model Impact"},{"line_number":91,"context_line":"-----------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"#. Adds a new table for address scopes."},{"line_number":94,"context_line":"#. Adds a new field (default null) to the SubnetPool referencing a single"},{"line_number":95,"context_line":"   AddressScope."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_33863614","line":93,"updated":"2015-05-27 09:46:05.000000000","message":"It is not clear to me which information an address scope should have. A single id will be enough?","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7505,"name":"Jaume Devesa","email":"devvesa@gmail.com","username":"devesa"},"change_message_id":"0ce1d63a54f538b021ac535a9b4436f84b74af2b","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Data Model Impact"},{"line_number":91,"context_line":"-----------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"#. Adds a new table for address scopes."},{"line_number":94,"context_line":"#. Adds a new field (default null) to the SubnetPool referencing a single"},{"line_number":95,"context_line":"   AddressScope."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_f4c9567a","line":93,"in_reply_to":"7a016987_0edd2842","updated":"2015-05-28 11:37:57.000000000","message":"If we want to look like VRF (didn\u0027t know about them before read this spec, but now it makes a lot of sense to me), maybe a 4-byte tag (maybe even autoassigned by Neutron) would be enough.\nWe may even leverage it into the implementation in a future.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"b580ed9fe98b5d6eb30483fb66f299ed9ff752a5","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Data Model Impact"},{"line_number":91,"context_line":"-----------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"#. Adds a new table for address scopes."},{"line_number":94,"context_line":"#. Adds a new field (default null) to the SubnetPool referencing a single"},{"line_number":95,"context_line":"   AddressScope."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_0edd2842","line":93,"in_reply_to":"7a016987_33863614","updated":"2015-05-27 14:34:30.000000000","message":"A name? A route target? Or a default RD? I think this depends on how the routing would work and I don\u0027t think we\u0027ve nailed that down, nor decided how complex we want to make it. Do we want this to look like a VRF with a default RD and the ability to export routes via route targets? Or is that making it too hard for the use cases we want to solve?\n\nI was hoping to get more feedback from the operator community at the summit but I guess that was just a pipe dream :)","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"d45bfb2d86edf5e8252eef780c63a2709bd76a31","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Data Model Impact"},{"line_number":91,"context_line":"-----------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"#. Adds a new table for address scopes."},{"line_number":94,"context_line":"#. Adds a new field (default null) to the SubnetPool referencing a single"},{"line_number":95,"context_line":"   AddressScope."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_b0707841","line":93,"in_reply_to":"7a016987_f4c9567a","updated":"2015-05-28 18:26:22.000000000","message":"An Id and name are what I was going to start with.  It isn\u0027t clear to me how their association with RTs and RDs should be handled.  Should that be handled in the association with a BGP or other DR object?","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"2c8ae24290596c1b3fa218699aec6f9147a08a5e","unresolved":false,"context_lines":[{"line_number":92,"context_line":""},{"line_number":93,"context_line":"#. Adds a new table for address scopes."},{"line_number":94,"context_line":"#. Adds a new field (default null) to the SubnetPool referencing a single"},{"line_number":95,"context_line":"   AddressScope."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"REST API Impact"},{"line_number":98,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_cde6e4e7","line":95,"updated":"2015-05-27 21:43:30.000000000","message":"Are you envisioning address_scope_id being an updateable field? I\u0027m inclined to make it read-only for now. Moving subnetpools between scopes seems to add a little more complexity than we probably want at this point.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"d45bfb2d86edf5e8252eef780c63a2709bd76a31","unresolved":false,"context_lines":[{"line_number":92,"context_line":""},{"line_number":93,"context_line":"#. Adds a new table for address scopes."},{"line_number":94,"context_line":"#. Adds a new field (default null) to the SubnetPool referencing a single"},{"line_number":95,"context_line":"   AddressScope."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"REST API Impact"},{"line_number":98,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_3085a8ce","line":95,"in_reply_to":"7a016987_adb84876","updated":"2015-05-28 18:26:22.000000000","message":"Essentially all subnets in the implicit pool are automatically part of the implicit address scope.  It needs to work the same as it does today for those subnets, allowing overlap, etc.\n\nYes, I envision the address pool being updatable.  Otherwise, you\u0027d have to recreate all of your pools, subnets, etc. in order to take advantage of address scopes.  It will have its challenges.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"dae3e8aba2021fcf98a93fc00e9ed0f61bdb2e07","unresolved":false,"context_lines":[{"line_number":92,"context_line":""},{"line_number":93,"context_line":"#. Adds a new table for address scopes."},{"line_number":94,"context_line":"#. Adds a new field (default null) to the SubnetPool referencing a single"},{"line_number":95,"context_line":"   AddressScope."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"REST API Impact"},{"line_number":98,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_adb84876","line":95,"in_reply_to":"7a016987_cde6e4e7","updated":"2015-05-27 21:52:12.000000000","message":"I may have missed this, but it sounds like there is an \"implict\" address scope that is similar to the implicit subnet pool.  In the case of the implicit subnet pool, it behaves differently from explicit subnet pools in that it allows for overlapping addresses and mixes address families together. This is for purposes of maintaining backward-compatibility. How do you envision the implicit address scope behaving? Do we allow overlapping prefixes for backward-compatibility and treat it similarly to the implicit subnet pool in that it plays by different rules than the explicit address scopes?","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":6659,"name":"Paul Michali","email":"pc@michali.net","username":"pcm"},"change_message_id":"d420c45b989984cded859dbdd572bc419090b138","unresolved":false,"context_lines":[{"line_number":124,"context_line":"---------------------"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"#. The python-neutron client will be enhanced to operate on address scopes"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"Performance Impact"},{"line_number":129,"context_line":"------------------"},{"line_number":130,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_e7b83813","line":127,"updated":"2015-05-21 21:49:24.000000000","message":"Horizon support?","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"d45bfb2d86edf5e8252eef780c63a2709bd76a31","unresolved":false,"context_lines":[{"line_number":124,"context_line":"---------------------"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"#. The python-neutron client will be enhanced to operate on address scopes"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"Performance Impact"},{"line_number":129,"context_line":"------------------"},{"line_number":130,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_d04bf4af","line":127,"in_reply_to":"7a016987_e7b83813","updated":"2015-05-28 18:26:22.000000000","message":"Do we have a volunteer?  Honestly, I\u0027ve found it difficult to find Horizon developers willing and able to work on these features.  Do we need to commit to Horizon support in order to develop the API?  From what I know about Horizon, they\u0027re off rearchitecting everything and have little interest in new Neutron APIs.  That might just be Horizon devs from one particular company, though.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7505,"name":"Jaume Devesa","email":"devvesa@gmail.com","username":"devesa"},"change_message_id":"8a4f6ea23ebad80d412499b1cc2d695cb341cd2d","unresolved":false,"context_lines":[{"line_number":163,"context_line":"Community Impact"},{"line_number":164,"context_line":"----------------"},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"The community will love it.  ;)"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"Seriously though, this allows Neutron L3 to know where stuff can be routed."},{"line_number":169,"context_line":"This is important especially with IPv6 where we want to just route through to"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_33451617","line":166,"updated":"2015-05-27 09:46:05.000000000","message":"Indeed!","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":6659,"name":"Paul Michali","email":"pc@michali.net","username":"pcm"},"change_message_id":"d420c45b989984cded859dbdd572bc419090b138","unresolved":false,"context_lines":[{"line_number":205,"context_line":""},{"line_number":206,"context_line":"#. Add address scope id to RPC response to L3 agent.  (Initially just the"},{"line_number":207,"context_line":"   subnet pool id)"},{"line_number":208,"context_line":"#. Enhance L3 agent to honer address scopes in routing tables and policy"},{"line_number":209,"context_line":"   routing.  Initially just subnet pool id.  It must be able to handle changing"},{"line_number":210,"context_line":"   scope ids for any given port."},{"line_number":211,"context_line":"#. Add DB model for address scopes."}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_ed1499e9","line":208,"updated":"2015-05-21 21:49:24.000000000","message":"honer -\u003e honor","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"d45bfb2d86edf5e8252eef780c63a2709bd76a31","unresolved":false,"context_lines":[{"line_number":205,"context_line":""},{"line_number":206,"context_line":"#. Add address scope id to RPC response to L3 agent.  (Initially just the"},{"line_number":207,"context_line":"   subnet pool id)"},{"line_number":208,"context_line":"#. Enhance L3 agent to honer address scopes in routing tables and policy"},{"line_number":209,"context_line":"   routing.  Initially just subnet pool id.  It must be able to handle changing"},{"line_number":210,"context_line":"   scope ids for any given port."},{"line_number":211,"context_line":"#. Add DB model for address scopes."}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_70f4405a","line":208,"in_reply_to":"7a016987_ed1499e9","updated":"2015-05-28 18:26:22.000000000","message":"Doh!  Done.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7505,"name":"Jaume Devesa","email":"devvesa@gmail.com","username":"devesa"},"change_message_id":"8a4f6ea23ebad80d412499b1cc2d695cb341cd2d","unresolved":false,"context_lines":[{"line_number":211,"context_line":"#. Add DB model for address scopes."},{"line_number":212,"context_line":"#. Add CRUD for AddressScope, including association with SubnetPool.  Update"},{"line_number":213,"context_line":"   the Neutron server to send the appropriate scope instead of the pool."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Dependencies"},{"line_number":217,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_445e6d77","line":214,"updated":"2015-05-27 09:46:05.000000000","message":"Imagine a tenant has two tenant networks associated to the same router before Liberty? Shouldn\u0027t be an upgrade process (db only?) to associate these networks to the same address scope?","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"d45bfb2d86edf5e8252eef780c63a2709bd76a31","unresolved":false,"context_lines":[{"line_number":211,"context_line":"#. Add DB model for address scopes."},{"line_number":212,"context_line":"#. Add CRUD for AddressScope, including association with SubnetPool.  Update"},{"line_number":213,"context_line":"   the Neutron server to send the appropriate scope instead of the pool."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Dependencies"},{"line_number":217,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a016987_70c200eb","line":214,"in_reply_to":"7a016987_445e6d77","updated":"2015-05-28 18:26:22.000000000","message":"It depends on their subnet pools.  If they were both from the same subnet pool then they will magically be part of the same address scope.  If they weren\u0027t, I\u0027m not sure I want to make any decisions about what address scopes to put them in to.","commit_id":"3669dae0b1c96d01f0d8cadc3dc19eb6418b1eb1"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"f8598d6d5e31d2374b7a50e6210d07b4936b358f","unresolved":false,"context_lines":[{"line_number":37,"context_line":"Neutron L3 provides a limited routing solution to isolate between projects.  As"},{"line_number":38,"context_line":"long as routers only connect one project\u0027s internal networks, floating ips will"},{"line_number":39,"context_line":"work it out between projects.  But, this is easily broken.  A project could"},{"line_number":40,"context_line":"attempt routing between two internal networks with the same subnet address."},{"line_number":41,"context_line":"If routers are plugged in to shared networks, things could get uglier."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"With IPv6, we want to forget floating IPs and route straight in to tenant"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_f4e364d6","line":40,"updated":"2015-05-29 13:38:57.000000000","message":"when a subnet is added into a router, address overlapping will be detected, right?\n\nAlso address overlapping is currently not allowed for subnets in the same network","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"96138900273dd55376138d53bc59522591c02896","unresolved":false,"context_lines":[{"line_number":37,"context_line":"Neutron L3 provides a limited routing solution to isolate between projects.  As"},{"line_number":38,"context_line":"long as routers only connect one project\u0027s internal networks, floating ips will"},{"line_number":39,"context_line":"work it out between projects.  But, this is easily broken.  A project could"},{"line_number":40,"context_line":"attempt routing between two internal networks with the same subnet address."},{"line_number":41,"context_line":"If routers are plugged in to shared networks, things could get uglier."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"With IPv6, we want to forget floating IPs and route straight in to tenant"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5afe65bd_e6718e45","line":40,"in_reply_to":"7a016987_152717b7","updated":"2015-06-04 14:51:31.000000000","message":"I may have misunderstood, but see below.\nopenstack@ip6-devstack-41:~/devstack$ neutron router-interface-add router1 mysub2\nBad router request: Cidr 10.0.0.0/16 of subnet 45109e68-0346-4a87-b45f-a77f103713d9 overlaps with cidr 10.0.0.0/24 of subnet caaa5e75-466c-4b57-b9bb-d48ab875698a","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"93549c56c76c6f22c879a873c02517280f30a2c6","unresolved":false,"context_lines":[{"line_number":37,"context_line":"Neutron L3 provides a limited routing solution to isolate between projects.  As"},{"line_number":38,"context_line":"long as routers only connect one project\u0027s internal networks, floating ips will"},{"line_number":39,"context_line":"work it out between projects.  But, this is easily broken.  A project could"},{"line_number":40,"context_line":"attempt routing between two internal networks with the same subnet address."},{"line_number":41,"context_line":"If routers are plugged in to shared networks, things could get uglier."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"With IPv6, we want to forget floating IPs and route straight in to tenant"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_152717b7","line":40,"in_reply_to":"7a016987_f4e364d6","updated":"2015-06-01 19:00:47.000000000","message":"Currently, no.  There is nothing to detect address overlap.\n\nAddress overlap within a network is beside the point.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"f8598d6d5e31d2374b7a50e6210d07b4936b358f","unresolved":false,"context_lines":[{"line_number":43,"context_line":"With IPv6, we want to forget floating IPs and route straight in to tenant"},{"line_number":44,"context_line":"networks.  We can\u0027t just turn on routing assuming that everything will just"},{"line_number":45,"context_line":"work.  How can we tell the difference between a valid, unique, and globally"},{"line_number":46,"context_line":"routable subnet and one that someone just made up while filling out the subnet"},{"line_number":47,"context_line":"create details?"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Also, the full integration of MPLS/BGP VPN in to Neutron has been blocked by"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_f4b24495","line":46,"updated":"2015-05-29 13:38:57.000000000","message":"But how do we tell with Address Scopes? Can you clarify?","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"93549c56c76c6f22c879a873c02517280f30a2c6","unresolved":false,"context_lines":[{"line_number":43,"context_line":"With IPv6, we want to forget floating IPs and route straight in to tenant"},{"line_number":44,"context_line":"networks.  We can\u0027t just turn on routing assuming that everything will just"},{"line_number":45,"context_line":"work.  How can we tell the difference between a valid, unique, and globally"},{"line_number":46,"context_line":"routable subnet and one that someone just made up while filling out the subnet"},{"line_number":47,"context_line":"create details?"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Also, the full integration of MPLS/BGP VPN in to Neutron has been blocked by"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5afe65bd_08efa7b1","line":46,"in_reply_to":"7a016987_bc94a78a","updated":"2015-06-01 19:00:47.000000000","message":"Anyone can create an address scope but only an admin can link it to subnet pools owned by other tenants.  Also, straight routing to an external network will only work if the address scope of the external network matches that of the internal network.  Only an admin can make this association.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"3c6d6f33255fd6c20bb19aa1a6177a59afb86e0a","unresolved":false,"context_lines":[{"line_number":43,"context_line":"With IPv6, we want to forget floating IPs and route straight in to tenant"},{"line_number":44,"context_line":"networks.  We can\u0027t just turn on routing assuming that everything will just"},{"line_number":45,"context_line":"work.  How can we tell the difference between a valid, unique, and globally"},{"line_number":46,"context_line":"routable subnet and one that someone just made up while filling out the subnet"},{"line_number":47,"context_line":"create details?"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Also, the full integration of MPLS/BGP VPN in to Neutron has been blocked by"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_f7180386","line":46,"in_reply_to":"7a016987_f4b24495","updated":"2015-05-29 15:21:40.000000000","message":"AddressScopes themselves don\u0027t necessarily tell us anything, they are a tool that can be used by the operator to express, advertise, and enforce routability of prefixes within different contexts.\n\nSuppose an operator has some globally routable IPv6 prefixes at their disposal.  The operator can create an AddressScope with subnetpools that contain these prefixes, name the AddressScope something like \"Global IPv6\", and let their tenants know that they should be using this scope for direct internet access. When using an AddressScope, tenants are forced to use only prefixes available inside the AddressScope to address their subnets. Bring-your-own-addressing is not allowed from a tenant perspective.\n\nIn this scenario the problem of determining and advertising to tenants whether a prefix is valid/routable is solved using AddressScopes as a tool.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"2b284e36b5cdcfff1f92beb65a3b8daf50192102","unresolved":false,"context_lines":[{"line_number":43,"context_line":"With IPv6, we want to forget floating IPs and route straight in to tenant"},{"line_number":44,"context_line":"networks.  We can\u0027t just turn on routing assuming that everything will just"},{"line_number":45,"context_line":"work.  How can we tell the difference between a valid, unique, and globally"},{"line_number":46,"context_line":"routable subnet and one that someone just made up while filling out the subnet"},{"line_number":47,"context_line":"create details?"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Also, the full integration of MPLS/BGP VPN in to Neutron has been blocked by"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_bc94a78a","line":46,"in_reply_to":"7a016987_f7180386","updated":"2015-05-29 19:12:14.000000000","message":"Ok, a follow up question is who can create an address scope? In the above scenario, the address scope is created by an operator.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"f5d35271bc839e0973f9a0c23961c446db27e0c6","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":68,"context_line":"alone in its own address scope.  The id of the subnet pool will be used as the"},{"line_number":69,"context_line":"id of the address scope."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_fdc24884","line":69,"updated":"2015-05-28 19:03:49.000000000","message":"I hadn\u0027t fully processed this point until now.  Is there a particular reason to attach a scope_id to a subnetpool in all cases that you\u0027ve thought of? I think what you\u0027re suggesting is perfectly reasonable, I\u0027m curious what led you away from suggesting a null scope_id when a subnetpool is not associated with an AddressScope.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"b4c7da709625ee92c6bf74f0f27058ae745f4c92","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":68,"context_line":"alone in its own address scope.  The id of the subnet pool will be used as the"},{"line_number":69,"context_line":"id of the address scope."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_36e91db8","line":69,"in_reply_to":"7a016987_607fcb17","updated":"2015-05-28 21:01:54.000000000","message":"Thanks for the explanation. I think what you\u0027re suggesting is a good direction.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"116ce1c9593552cbd0904aef15f4e40d454d6082","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":68,"context_line":"alone in its own address scope.  The id of the subnet pool will be used as the"},{"line_number":69,"context_line":"id of the address scope."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_607fcb17","line":69,"in_reply_to":"7a016987_fdc24884","updated":"2015-05-28 19:57:28.000000000","message":"I actually entertained this as an alternative (my comment on PS5 L69).  I do think of null address scope but I was thinking of only the subnets from the null subnet pool being a part of it.\n\nIs the null address scope the same across tenants?  Or, is there one per tenant?  Either answer brings up more questions, especially if you try to include a subnet pool in to a null address scope by default.  Here are some things to think about:\n\n- Are subnets from the implicit pool in the same scope even across tenants?  I wouldn\u0027t think so.  If they were, then we would expect to route between legacy tenant private networks and legacy external networks without NAT unless we come up with some other rule.\n\n- I think that subnets from the same explicit pool should always be in the same address scope even if they belong to different tenants (shared address pool) and when there is no address scope (which I imagine will be the case when we upgrade a Kilo deployment to Liberty)\n\n- If the null address scopes are per tenant, what scope is a shared pool in by default?  Does it make sense to consider it in the same scope as other pools owned by the same tenant?\n\n- Does it make sense for any two explicit pools to be considered to be in the same scope by default?  I kind of don\u0027t think so.\n\nI think I\u0027ve talked myself in to sticking with this as written for now.  Subnet pools by default are considered isolated in their own implicit scope.  The uuid used is an implementation detail as was pointed out in PS5.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"f8598d6d5e31d2374b7a50e6210d07b4936b358f","unresolved":false,"context_lines":[{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"},{"line_number":73,"context_line":"connecting to networks with different address scopes.  The incoming device"},{"line_number":74,"context_line":"(iif) will be specified with each rule."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Subnets on a network will be constrained to the same subnet pool [#]_.  Even if"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_54ec78ba","line":73,"updated":"2015-05-29 13:38:57.000000000","message":"Can you elaborate how to implement connecting to networks with different address scopes? Would it be some new form of APIs to import/export routes between the routing tables?","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"96138900273dd55376138d53bc59522591c02896","unresolved":false,"context_lines":[{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"},{"line_number":73,"context_line":"connecting to networks with different address scopes.  The incoming device"},{"line_number":74,"context_line":"(iif) will be specified with each rule."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Subnets on a network will be constrained to the same subnet pool [#]_.  Even if"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5afe65bd_a965a7b5","line":73,"in_reply_to":"5afe65bd_4b091931","updated":"2015-06-04 14:51:31.000000000","message":"Ok, my misunderstanding. I thought it means that packets can be forwarded between the networks with different address scopes. In the case of VRF, packets can be forwarded between, for example, the global vrf and other vrfs defined in the system.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"42067fdd732e2b4e4ff08813772ee0c82aa2945a","unresolved":false,"context_lines":[{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"},{"line_number":73,"context_line":"connecting to networks with different address scopes.  The incoming device"},{"line_number":74,"context_line":"(iif) will be specified with each rule."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Subnets on a network will be constrained to the same subnet pool [#]_.  Even if"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5afe65bd_c9c90328","line":73,"in_reply_to":"5afe65bd_a965a7b5","updated":"2015-06-04 15:00:07.000000000","message":"This is a good point that is not addressed in the spec. We may want a way that an administrator can allow route leaking between address scopes to handle things like shared services within the cloud.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"93549c56c76c6f22c879a873c02517280f30a2c6","unresolved":false,"context_lines":[{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"},{"line_number":73,"context_line":"connecting to networks with different address scopes.  The incoming device"},{"line_number":74,"context_line":"(iif) will be specified with each rule."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Subnets on a network will be constrained to the same subnet pool [#]_.  Even if"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5afe65bd_4b091931","line":73,"in_reply_to":"7a016987_54ec78ba","updated":"2015-06-01 19:00:47.000000000","message":"There will be no new API.  Each port of a router will be assigned an address scope based on the address scope found on the attached network.  Multiple routing tables will represent multiple scopes.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"f8598d6d5e31d2374b7a50e6210d07b4936b358f","unresolved":false,"context_lines":[{"line_number":71,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":72,"context_line":"implementation will use multiple routing tables and policy routing to implement"},{"line_number":73,"context_line":"connecting to networks with different address scopes.  The incoming device"},{"line_number":74,"context_line":"(iif) will be specified with each rule."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Subnets on a network will be constrained to the same subnet pool [#]_.  Even if"},{"line_number":77,"context_line":"there are multiple pools in a scope, a network will be constrained to only one"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_34969cf0","line":74,"updated":"2015-05-29 13:38:57.000000000","message":"What is the applicability of the address scopes? In a tenant router, or a shared router, or admin created router? I\u0027d like to see it be clarified.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"b4c7da709625ee92c6bf74f0f27058ae745f4c92","unresolved":false,"context_lines":[{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Subnets on a network will be constrained to the same subnet pool [#]_.  Even if"},{"line_number":77,"context_line":"there are multiple pools in a scope, a network will be constrained to only one"},{"line_number":78,"context_line":"pool."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":".. [#] https://bugs.launchpad.net/neutron/+bug/1451559"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_365c7d7c","line":78,"updated":"2015-05-28 21:01:54.000000000","message":"Just a clarification: we are enforcing that subnets from the same address family must be allocated from the same pool. If we blindly enforced that all subnets be allocated from the same pool we would break support for dual-stack networks.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"93549c56c76c6f22c879a873c02517280f30a2c6","unresolved":false,"context_lines":[{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Subnets on a network will be constrained to the same subnet pool [#]_.  Even if"},{"line_number":77,"context_line":"there are multiple pools in a scope, a network will be constrained to only one"},{"line_number":78,"context_line":"pool."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":".. [#] https://bugs.launchpad.net/neutron/+bug/1451559"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5afe65bd_0b032111","line":78,"in_reply_to":"7a016987_365c7d7c","updated":"2015-06-01 19:00:47.000000000","message":"Done","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"116ce1c9593552cbd0904aef15f4e40d454d6082","unresolved":false,"context_lines":[{"line_number":79,"context_line":""},{"line_number":80,"context_line":".. [#] https://bugs.launchpad.net/neutron/+bug/1451559"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"NAT will be automatically included between any ipv4 scope and an ipv4"},{"line_number":83,"context_line":"\"external\" network to which a router is connected as a gateway if the external"},{"line_number":84,"context_line":"network has a different scope.  It will provide 1-1 NAT for floating IPs and"},{"line_number":85,"context_line":"many-1 for default SNAT.  This will support existing use cases.  I don\u0027t intend"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_00013738","line":82,"updated":"2015-05-28 19:57:28.000000000","message":"We might need to expound a bit about how subnets in the implicit pool are handled.\n\n- Are there current use cases where a router is used to cross-plug different tenants using these subnets and expects to route between them without NAT?  If so, and we start considering them different scopes, that could break.\n\n- Are there cases where an external network and an internal network are both owned by the same tenant, weren\u0027t created from a pool, and still we NAT between them just because the router is connected to the external network with an \"external gateway?\"","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"faeace9143e0be035ee6e33c8b12dc1a611aff62","unresolved":false,"context_lines":[{"line_number":79,"context_line":""},{"line_number":80,"context_line":".. [#] https://bugs.launchpad.net/neutron/+bug/1451559"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"NAT will be automatically included between any ipv4 scope and an ipv4"},{"line_number":83,"context_line":"\"external\" network to which a router is connected as a gateway if the external"},{"line_number":84,"context_line":"network has a different scope.  It will provide 1-1 NAT for floating IPs and"},{"line_number":85,"context_line":"many-1 for default SNAT.  This will support existing use cases.  I don\u0027t intend"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_69f9dd4d","line":82,"in_reply_to":"7a016987_00013738","updated":"2015-05-29 13:17:05.000000000","message":"I have put together a drawing showing a sample topology. I think there are a lot more use cases too, and we need to lay them out one-by-one to understand how these all fit together. Let\u0027s use this as a straw man anyway, and if you want to see some other topologies on here let me know.\n\n\nhttps://infoblox.box.com/s/pnfxslfrynl32ng1bmkcwuc456lmqt4v\n\nSome of the questions this brought up for me that I think need to be addressed are:\n\n* Since \"external\" is a flag on the L2 network, how does it related to address scopes that are routable?\n\n* Take, for example, in the diagram Scope B (\"Internet\"). Do all of those subnets need to sit on various external networks? Or, could we instead advertise those routes upstream. I think it was Jaume in Paris talking about a \"Provider Router\" which would allow this sort of scenario more easily.\n\n* Where do floating IPs fit in then? If Scope B is all external nets, then floating IP works as it does today. But if Scope B is not external nets then we are having NAT between internal nets because of the different scopes.\n\n* Suppose now that Tenant Y wants to advertise their routes to the rest of their organization (NOT to the internet). In that case we could 1) Assign an route distinguisher for RY1, and export those routes with that RD and some RT; OR 2) assign an RD to Scope C and export the routes from there with some RT. In that case, we have to consider what happens with RY2. The 10.0.*.0 subnets .","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"f5d35271bc839e0973f9a0c23961c446db27e0c6","unresolved":false,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"You might realize here that a tenant could add any addresses he desires to the"},{"line_number":97,"context_line":"subnet pool after the admin linked it to a scope.  Should we prevent anyone but"},{"line_number":98,"context_line":"an admin or scope owner from updating subnet pools when they\u0027re in a scope?"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Data Model Impact"},{"line_number":101,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_3d590036","line":98,"updated":"2015-05-28 19:03:49.000000000","message":"Good question. I think we should prevent this. Updating the prefix list of a subnetpool has side-effects that ripple through the address scope. An admin or scope owner should be in control of that.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":7505,"name":"Jaume Devesa","email":"devvesa@gmail.com","username":"devesa"},"change_message_id":"af516cfcc045a579ea2478372a94f728446ebdd4","unresolved":false,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"You might realize here that a tenant could add any addresses he desires to the"},{"line_number":97,"context_line":"subnet pool after the admin linked it to a scope.  Should we prevent anyone but"},{"line_number":98,"context_line":"an admin or scope owner from updating subnet pools when they\u0027re in a scope?"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Data Model Impact"},{"line_number":101,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_5f8b7ec3","line":98,"in_reply_to":"7a016987_3d590036","updated":"2015-05-29 08:36:38.000000000","message":"Won\u0027t it be a function/feature that will look if SubnetPools don\u0027t overlap each other inside an AddressScope? Can\u0027t we rely on this function if a tenant want to update a SubnetPool?","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"3c6d6f33255fd6c20bb19aa1a6177a59afb86e0a","unresolved":false,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"You might realize here that a tenant could add any addresses he desires to the"},{"line_number":97,"context_line":"subnet pool after the admin linked it to a scope.  Should we prevent anyone but"},{"line_number":98,"context_line":"an admin or scope owner from updating subnet pools when they\u0027re in a scope?"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Data Model Impact"},{"line_number":101,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_9759cfff","line":98,"in_reply_to":"7a016987_5f8b7ec3","updated":"2015-05-29 15:21:40.000000000","message":"Yes, we will get overlap detection but that\u0027s beside the point.  This is not about preventing overlapping prefixes, it\u0027s about controlling what prefixes are made routable within an address scope. By adding a prefix to a subnetpool, you are making it routable across the address scope which affects all tenants using that scope.  I\u0027m not sure we want to give that power to the average user.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"93549c56c76c6f22c879a873c02517280f30a2c6","unresolved":false,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"You might realize here that a tenant could add any addresses he desires to the"},{"line_number":97,"context_line":"subnet pool after the admin linked it to a scope.  Should we prevent anyone but"},{"line_number":98,"context_line":"an admin or scope owner from updating subnet pools when they\u0027re in a scope?"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Data Model Impact"},{"line_number":101,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5afe65bd_1a2c89aa","line":98,"in_reply_to":"7a016987_9759cfff","updated":"2015-06-01 19:00:47.000000000","message":"Done","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"f8598d6d5e31d2374b7a50e6210d07b4936b358f","unresolved":false,"context_lines":[{"line_number":181,"context_line":""},{"line_number":182,"context_line":"The community will love it.  ;)"},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"Seriously though, this allows Neutron L3 to know where stuff can be routed."},{"line_number":185,"context_line":"This is important especially with IPv6 where we want to just route through to"},{"line_number":186,"context_line":"project\u0027s networks instead of using floating IPs to traverse the address scope"},{"line_number":187,"context_line":"boundary."}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a016987_547b58be","line":184,"updated":"2015-05-29 13:38:57.000000000","message":"Do you mean to say that this provides a means to group interfaces into routing domains?","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"93549c56c76c6f22c879a873c02517280f30a2c6","unresolved":false,"context_lines":[{"line_number":181,"context_line":""},{"line_number":182,"context_line":"The community will love it.  ;)"},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"Seriously though, this allows Neutron L3 to know where stuff can be routed."},{"line_number":185,"context_line":"This is important especially with IPv6 where we want to just route through to"},{"line_number":186,"context_line":"project\u0027s networks instead of using floating IPs to traverse the address scope"},{"line_number":187,"context_line":"boundary."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5afe65bd_2e5f0610","line":184,"in_reply_to":"7a016987_547b58be","updated":"2015-06-01 19:00:47.000000000","message":"Yes, but indirectly.  Interfaces connect to networks which have subnets which can be allocated from pools associated with address scopes.  So, interfaces are thus grouped in to routing domains.","commit_id":"9a8e407eb9e3248f18b964551043cfdc8afa9689"},{"author":{"_account_id":14605,"name":"vikram.choudhary","email":"vikschw@gmail.com","username":"vikram.choudhary"},"change_message_id":"878f14823da427a3c44a832698ea7e1a9628329a","unresolved":false,"context_lines":[{"line_number":50,"context_line":"this.  An analog to address scopes in the L3 VPN world are route"},{"line_number":51,"context_line":"distinguishers.  With the addition of address scopes, we can easily map to"},{"line_number":52,"context_line":"route distinguishers.  This work is not in scope for this blueprint but will be"},{"line_number":53,"context_line":"further enabled by it."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/subnet-allocation"},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_a004dfbf","line":53,"updated":"2015-06-03 07:59:50.000000000","message":"I have a registered spec for this. Can we mention it here? (https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol)","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"1a7336d6ded15d209968effd5fd73c0fa1945eac","unresolved":false,"context_lines":[{"line_number":50,"context_line":"this.  An analog to address scopes in the L3 VPN world are route"},{"line_number":51,"context_line":"distinguishers.  With the addition of address scopes, we can easily map to"},{"line_number":52,"context_line":"route distinguishers.  This work is not in scope for this blueprint but will be"},{"line_number":53,"context_line":"further enabled by it."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/subnet-allocation"},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_fffdb63a","line":53,"in_reply_to":"5afe65bd_a004dfbf","updated":"2015-06-03 22:29:46.000000000","message":"Could you expound a bit on the \"prefix clashing issue\" in the blueprint?  I think I get your meaning at but it would help to me clearer in the blueprint description.\n\nAlso, I will add a reference to this blueprint.","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"18ae2865588986f3954d02b4d0d88ba5537317f6","unresolved":false,"context_lines":[{"line_number":52,"context_line":"route distinguishers.  This work is not in scope for this blueprint but will be"},{"line_number":53,"context_line":"further enabled by it."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/subnet-allocation"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Proposed Change"},{"line_number":58,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_b3d41f20","line":55,"updated":"2015-06-03 18:03:47.000000000","message":"nit: remove this line?","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"1a7336d6ded15d209968effd5fd73c0fa1945eac","unresolved":false,"context_lines":[{"line_number":52,"context_line":"route distinguishers.  This work is not in scope for this blueprint but will be"},{"line_number":53,"context_line":"further enabled by it."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/subnet-allocation"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Proposed Change"},{"line_number":58,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_df1c3ac3","line":55,"in_reply_to":"5afe65bd_b3d41f20","updated":"2015-06-03 22:29:46.000000000","message":"I\u0027ll move it up by where it is referenced.  Thanks.","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":14605,"name":"vikram.choudhary","email":"vikschw@gmail.com","username":"vikram.choudhary"},"change_message_id":"878f14823da427a3c44a832698ea7e1a9628329a","unresolved":false,"context_lines":[{"line_number":67,"context_line":"then it must be an admin."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":70,"context_line":"alone in its own address scope."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":73,"context_line":"implementation will use multiple routing tables and policy routing to implement"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_20b58fed","line":70,"updated":"2015-06-03 07:59:50.000000000","message":"You mean a default address scope record will be created for unassigned SubnetPools?","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"1a7336d6ded15d209968effd5fd73c0fa1945eac","unresolved":false,"context_lines":[{"line_number":67,"context_line":"then it must be an admin."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"A SubnetPool which is not associated with an AddressScope will be considered"},{"line_number":70,"context_line":"alone in its own address scope."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":73,"context_line":"implementation will use multiple routing tables and policy routing to implement"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_7f130667","line":70,"in_reply_to":"5afe65bd_20b58fed","updated":"2015-06-03 22:29:46.000000000","message":"I wasn\u0027t thinking that an explicit address scope would be created for this.  However, in the router, traffic from/to these subnet pools would be handled as if they were in their own address scope.\n\nDo you see a benefit for creating an explicit address scope for them?","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":14605,"name":"vikram.choudhary","email":"vikschw@gmail.com","username":"vikram.choudhary"},"change_message_id":"878f14823da427a3c44a832698ea7e1a9628329a","unresolved":false,"context_lines":[{"line_number":70,"context_line":"alone in its own address scope."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":73,"context_line":"implementation will use multiple routing tables and policy routing to implement"},{"line_number":74,"context_line":"connecting to networks with different address scopes.  The incoming device"},{"line_number":75,"context_line":"(iif) will be specified with each rule."},{"line_number":76,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_20ac6f9f","line":73,"updated":"2015-06-03 07:59:50.000000000","message":"Does policy routing already exist in neutron?","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"1a7336d6ded15d209968effd5fd73c0fa1945eac","unresolved":false,"context_lines":[{"line_number":70,"context_line":"alone in its own address scope."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Neutron routers will be aware of address scopes.  The reference L3"},{"line_number":73,"context_line":"implementation will use multiple routing tables and policy routing to implement"},{"line_number":74,"context_line":"connecting to networks with different address scopes.  The incoming device"},{"line_number":75,"context_line":"(iif) will be specified with each rule."},{"line_number":76,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_1f15313f","line":73,"in_reply_to":"5afe65bd_20ac6f9f","updated":"2015-06-03 22:29:46.000000000","message":"Policy routing is a Linux feature which can be implemented using iproute tools.  This is an implementation detail for the reference implementation.","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":14258,"name":"Ryan Tidwell","email":"rktidwell85@gmail.com","username":"tidwellr"},"change_message_id":"18ae2865588986f3954d02b4d0d88ba5537317f6","unresolved":false,"context_lines":[{"line_number":79,"context_line":"pool per address family.  This work has already been completed and backported"},{"line_number":80,"context_line":"to Kilo."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. [#] https://bugs.launchpad.net/neutron/+bug/1451559"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"NAT will be automatically included between an internal network and an"},{"line_number":85,"context_line":"\"external\" network to which a router is connected as a gateway *unless* the two"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_53872bd7","line":82,"updated":"2015-06-03 18:03:47.000000000","message":"Do we need this limitation? Technically speaking I don\u0027t think so. The general approach to solving this bug was to enforce prefix uniqueness by making sure the allocation was from the same pool.  With address scopes, that could really be loosened to allow allocation from different pools as long as the address scope is shared.  The prefix uniqueness would is enforced at the address scope level, so we don\u0027t have to restrict to the same subnetpool.  It\u0027s probably adding more scope to relax this constraint, so the spec still gets a +1 from me.  This is just some food for thought.","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"1a7336d6ded15d209968effd5fd73c0fa1945eac","unresolved":false,"context_lines":[{"line_number":79,"context_line":"pool per address family.  This work has already been completed and backported"},{"line_number":80,"context_line":"to Kilo."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. [#] https://bugs.launchpad.net/neutron/+bug/1451559"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"NAT will be automatically included between an internal network and an"},{"line_number":85,"context_line":"\"external\" network to which a router is connected as a gateway *unless* the two"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_9fea410e","line":82,"in_reply_to":"5afe65bd_53872bd7","updated":"2015-06-03 22:29:46.000000000","message":"Good food for thought.  I went back and forth on this when I wrote this considering exactly what you suggest.\n\nOne problem is that if a subnet pool is moved to another address scope, you would have to check all existing subnets to see if the constraint is now violated.  That started hurting my brain so I that it would be best to defer relaxing this constraint.","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"ab95cfda825f5acc0d2d319143ca82771d9b88ba","unresolved":false,"context_lines":[{"line_number":125,"context_line":"REST API Impact"},{"line_number":126,"context_line":"---------------"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"TODO(Carl) Flesh out the details here."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Basically, we add CRUD semantics for the new address scope object.  This"},{"line_number":131,"context_line":"includes a field for associated subnet pools."}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_246583e0","line":128,"updated":"2015-06-03 19:03:02.000000000","message":"Given the reduced spec requirements do we really need to detail these here? I mean, I think they are probably pretty straightforward.","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"1a7336d6ded15d209968effd5fd73c0fa1945eac","unresolved":false,"context_lines":[{"line_number":125,"context_line":"REST API Impact"},{"line_number":126,"context_line":"---------------"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"TODO(Carl) Flesh out the details here."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Basically, we add CRUD semantics for the new address scope object.  This"},{"line_number":131,"context_line":"includes a field for associated subnet pools."}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_9f892129","line":128,"in_reply_to":"5afe65bd_246583e0","updated":"2015-06-03 22:29:46.000000000","message":"I added a little bit of detail for the next PS.  But, you\u0027re probably right.  It may not need to be specified in excruciating detail.","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"ab95cfda825f5acc0d2d319143ca82771d9b88ba","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"TODO:  Notifications to routers on..."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"#. Create/Update/Delete of Address Scopes sends an update for routers connected"},{"line_number":145,"context_line":"   to affected subnets.  The scope of any subnet belonging to a subnet pool can"},{"line_number":146,"context_line":"   be changed."},{"line_number":147,"context_line":"#. RPC data for a router sent to the L3 agent will be enhanced by adding the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_a4785390","line":144,"updated":"2015-06-03 19:03:02.000000000","message":"Are there any constraints on when a scope can be updated or deleted? If not, what happens to associated subnet pools when a scope is deleted?","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"1a7336d6ded15d209968effd5fd73c0fa1945eac","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"TODO:  Notifications to routers on..."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"#. Create/Update/Delete of Address Scopes sends an update for routers connected"},{"line_number":145,"context_line":"   to affected subnets.  The scope of any subnet belonging to a subnet pool can"},{"line_number":146,"context_line":"   be changed."},{"line_number":147,"context_line":"#. RPC data for a router sent to the L3 agent will be enhanced by adding the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5afe65bd_1fa531a1","line":144,"in_reply_to":"5afe65bd_a4785390","updated":"2015-06-03 22:29:46.000000000","message":"I think the subnet pools would go back to being in their own little scopes.  What do you think?","commit_id":"baa49fbe599437ec79fef00477a80d7c25fcda29"},{"author":{"_account_id":10980,"name":"Doug Wiegley","email":"dougwig@parkside.io","username":"dougw"},"change_message_id":"2ee26386360c14df58e82c18d102815152aa4f98","unresolved":false,"context_lines":[{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_725304e3","line":20,"updated":"2015-06-09 20:03:13.000000000","message":"address flavors  *ducks and to avoid getting hit*\n\nMore seriously, scopes, to me, are restrictive.  After reading this spec, it seems more like what you\u0027re calling an address scope is really a group of related/trusted networks. It took me the entire spec to get to that understanding, though.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"329280545a9bd38393d5a4feda8f43198383b2b5","unresolved":false,"context_lines":[{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_82c62f98","line":20,"in_reply_to":"3afb71cf_0d7b958d","updated":"2015-06-09 21:34:02.000000000","message":"\"NAT-free routing zones\"\n\n\"native L3 groups\"\n\n\"overlaplessies\"\n\nAn scope is a way to identify that you will encounter no overlapping IPs within it. I think \"address scopes\" is okay, but I have been thinking about it with that term for quite a while now so I can see how it\u0027s not intuitive what it means by it\u0027s name.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"5f7dbbce533053bcdcb4cf05326101c37754d610","unresolved":false,"context_lines":[{"line_number":17,"context_line":""},{"line_number":18,"context_line":"This proposal has no relation to RFC 4007 IPv6 address scopes [#]_.  If you can"},{"line_number":19,"context_line":"come up with a better name for this than \"address scopes\" to avoid ambiguity,"},{"line_number":20,"context_line":"please suggest it here as a comment."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":".. [#] https://tools.ietf.org/html/rfc4007"},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_0d7b958d","line":20,"in_reply_to":"3afb71cf_725304e3","updated":"2015-06-09 20:27:39.000000000","message":"*takes a swing at Doug and misses*.  I was thinking about naming it \"dynamic group based policy addressing for vlan aware chained services with QoS across availability zones.\"  But, I thought address scopes just summed it up.\n\nGetting serious now...  Flavors don\u0027t seem quite right.  To me, flavors are about different implementations having different performance, security, or level of service properties.  Now, one might say that an address scope may have the \"property\" that it is usable on the internet but I don\u0027t think that makes it a flavor.\n\nAddress scopes are just for isolation at the L3 level and preventing overlap of addresses within a scope.  So, to say that it is a group of related networks is correct if a little vague.  We currently only have isolation at the L2 level in Neutron and we fake L3 isolation by slapping floating ips at the boundary.  That doesn\u0027t work for ipv6 at all.\n\nNot trusted.  It doesn\u0027t have anything to do with trust.  The entire global internet could be considered in the same scope but may not be trusted.  Different tenants may have addresses in the same scope.  I don\u0027t want to set the wrong expectation by putting the word trusted in here.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"329280545a9bd38393d5a4feda8f43198383b2b5","unresolved":false,"context_lines":[{"line_number":24,"context_line":"Problem Description"},{"line_number":25,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Neutron allows overlapping IP addresses.  Before Kilo, a subnet could be"},{"line_number":28,"context_line":"created with any cidr the user wanted to supply.  It didn\u0027t matter if the"},{"line_number":29,"context_line":"address overlapped with another subnet in the same project or another project."},{"line_number":30,"context_line":"Neutron provides isolation at the L2 level to ensure this can work."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_4218371e","line":27,"updated":"2015-06-09 21:34:02.000000000","message":"Even in Kilo I can do the same thing if I\u0027m not using subnetpools. Maybe \"Before subnetpools\"?","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"8a88fd809ddf87a0d97799245f37344614663ebb","unresolved":false,"context_lines":[{"line_number":24,"context_line":"Problem Description"},{"line_number":25,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Neutron allows overlapping IP addresses.  Before Kilo, a subnet could be"},{"line_number":28,"context_line":"created with any cidr the user wanted to supply.  It didn\u0027t matter if the"},{"line_number":29,"context_line":"address overlapped with another subnet in the same project or another project."},{"line_number":30,"context_line":"Neutron provides isolation at the L2 level to ensure this can work."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_58a2669a","line":27,"in_reply_to":"3afb71cf_4218371e","updated":"2015-06-10 17:54:18.000000000","message":"Done","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"329280545a9bd38393d5a4feda8f43198383b2b5","unresolved":false,"context_lines":[{"line_number":39,"context_line":"Neutron L3 provides a limited routing solution to isolate between projects.  As"},{"line_number":40,"context_line":"long as routers only connect one project\u0027s internal networks, floating ips will"},{"line_number":41,"context_line":"work it out between projects.  But, this is easily broken.  A project could"},{"line_number":42,"context_line":"attempt routing between two internal networks with the same subnet address."},{"line_number":43,"context_line":"If routers are plugged in to shared networks, things could get uglier."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"With IPv6, we want to forget floating IPs and route straight in to tenant"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_627b3329","line":42,"updated":"2015-06-09 21:34:02.000000000","message":"We actually have some protection for this already. It\u0027s just prohibited when CIDRs overlap: https://github.com/openstack/neutron/blob/185a761624e47d29797c1aab132930f4180ff6bf/neutron/db/l3_db.py#L479","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"8a88fd809ddf87a0d97799245f37344614663ebb","unresolved":false,"context_lines":[{"line_number":39,"context_line":"Neutron L3 provides a limited routing solution to isolate between projects.  As"},{"line_number":40,"context_line":"long as routers only connect one project\u0027s internal networks, floating ips will"},{"line_number":41,"context_line":"work it out between projects.  But, this is easily broken.  A project could"},{"line_number":42,"context_line":"attempt routing between two internal networks with the same subnet address."},{"line_number":43,"context_line":"If routers are plugged in to shared networks, things could get uglier."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"With IPv6, we want to forget floating IPs and route straight in to tenant"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_989b3e66","line":42,"in_reply_to":"3afb71cf_627b3329","updated":"2015-06-10 17:54:18.000000000","message":"Hmmm.  I was positive that I tried this and it worked.  But, today it doesn\u0027t work.  I must have not done something right.  Anyway, this point wasn\u0027t really all that important IMO.  I\u0027ll rewrite this section a bit.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"329280545a9bd38393d5a4feda8f43198383b2b5","unresolved":false,"context_lines":[{"line_number":53,"context_line":"distinguishers.  With the addition of address scopes, we can easily map to"},{"line_number":54,"context_line":"route distinguishers.  How address scopes relate to route distinguishers and"},{"line_number":55,"context_line":"the somewhat related route targets is out of scope for this blueprint.  Other"},{"line_number":56,"context_line":"blueprints like this one [#]_ will address this more completely."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_42d95721","line":56,"updated":"2015-06-09 21:34:02.000000000","message":"Why don\u0027t we call it \"route distinguisher\"? Is there anything that is incompatible between the terms? They seem to accomplish very similar things.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"8a88fd809ddf87a0d97799245f37344614663ebb","unresolved":false,"context_lines":[{"line_number":53,"context_line":"distinguishers.  With the addition of address scopes, we can easily map to"},{"line_number":54,"context_line":"route distinguishers.  How address scopes relate to route distinguishers and"},{"line_number":55,"context_line":"the somewhat related route targets is out of scope for this blueprint.  Other"},{"line_number":56,"context_line":"blueprints like this one [#]_ will address this more completely."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_7841a2a8","line":56,"in_reply_to":"3afb71cf_42d95721","updated":"2015-06-10 17:54:18.000000000","message":"Maybe because I\u0027ve been thinking about it for so long with the term \"address scopes\" that it is hard to switch.  I thought about using route distinguisher at one point but an RD is just a number and I didn\u0027t want to bring along all of the baggage about what an RD is and mostly how it should look.  If it is going to be a first class thing in Neutron it should have a uuid like everything in Neutron.  So, immediately it becomes more than just an RD.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"e0531dac178e60b08119940048c33c2bd21d96d7","unresolved":false,"context_lines":[{"line_number":53,"context_line":"distinguishers.  With the addition of address scopes, we can easily map to"},{"line_number":54,"context_line":"route distinguishers.  How address scopes relate to route distinguishers and"},{"line_number":55,"context_line":"the somewhat related route targets is out of scope for this blueprint.  Other"},{"line_number":56,"context_line":"blueprints like this one [#]_ will address this more completely."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_da80588d","line":56,"in_reply_to":"3afb71cf_5ffd7a6c","updated":"2015-06-10 20:57:54.000000000","message":"I did not intend to conflate the two concepts.  RDs and VRFs are building blocks that are used in industry to achieve L3 isolation.  Since Neutron has an overview of the entire virtual network topology in the cloud, I wanted a concept that reflects that.\n\nThe individual routers will have something like a VRF internally to maintain separate routing tables, but it isn\u0027t a full VRF (not yet anyway).  It is just an implementation detail as far as I\u0027m concerned.\n\nWe might also be able to one day add the ability to define rules for routes that can cross scopes, like what route targets (RTs) enable.  At that point, we could integrate RTs somewhere.  But that is potential future work.\n\nAlso, the UUID of an address scope is much like a route distinguisher (RD).   The similarity is not unnoticed.  However, I didn\u0027t want to just call it a route distinguisher.  To me, that would require using the the 64-bit format of an RD and constrain the concept.  I wanted an address scope to have a UUID like all other Neutron objects.   So, one day, an address scope may have a route distinguisher field or map to RDs in some other way.  But, for now, it is just an address scope.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":12912,"name":"John Belamaric","email":"jbelamaric@infoblox.com","username":"johnbelamaric"},"change_message_id":"7420577cc98266d136c3cf9b49457ae1d5084d1b","unresolved":false,"context_lines":[{"line_number":53,"context_line":"distinguishers.  With the addition of address scopes, we can easily map to"},{"line_number":54,"context_line":"route distinguishers.  How address scopes relate to route distinguishers and"},{"line_number":55,"context_line":"the somewhat related route targets is out of scope for this blueprint.  Other"},{"line_number":56,"context_line":"blueprints like this one [#]_ will address this more completely."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_dabdf802","line":56,"in_reply_to":"3afb71cf_5ffd7a6c","updated":"2015-06-10 20:25:41.000000000","message":"I think an address scope is neither. In an individual router we\u0027ll need a routing table per address scope, similar to a VRF. But an address scope is an abstraction that is not local to a router but rather is across the whole deployment.\n\nThen the question is whether address scopes play a role in how we advertise routes. I was thinking that, like in VRF, the RD would be an attribute of the relationship of the router to the address scope. So, there will be many RDs associated with any given address scope. \n\nOne option then would be to tag the address scope with an RT, so the upstream router would import that RT to get routes into the address scope.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"f84cf271221c4ae71c5bf366904fb7b9df94850e","unresolved":false,"context_lines":[{"line_number":53,"context_line":"distinguishers.  With the addition of address scopes, we can easily map to"},{"line_number":54,"context_line":"route distinguishers.  How address scopes relate to route distinguishers and"},{"line_number":55,"context_line":"the somewhat related route targets is out of scope for this blueprint.  Other"},{"line_number":56,"context_line":"blueprints like this one [#]_ will address this more completely."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":".. [#] https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_5ffd7a6c","line":56,"in_reply_to":"3afb71cf_7841a2a8","updated":"2015-06-10 20:14:46.000000000","message":"This spec mentioned both VRF and RD, but actually they are two different things. Would Address Scope be able to support both? Or should its use case be clearly defined?","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"329280545a9bd38393d5a4feda8f43198383b2b5","unresolved":false,"context_lines":[{"line_number":65,"context_line":"delegating parts of an address scope to different tenants.  The SubnetPools"},{"line_number":66,"context_line":"under an AddressScope must not overlap.  They must also be from the same"},{"line_number":67,"context_line":"address family.  Only an admin can associate an AddressScope and SubnetPool"},{"line_number":68,"context_line":"from different tenants.  Once a subnet pool has been associated, it can only be"},{"line_number":69,"context_line":"updated by the address scope owner.  If this owner is not the subnet pool owner"},{"line_number":70,"context_line":"then it must be an admin."},{"line_number":71,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_82b2af92","line":68,"updated":"2015-06-09 21:34:02.000000000","message":"These semantics sound hairy. IIUC, tenant A owns a pool. It gets associated to a scope owned by tenant B. Now neither tenant A nor tenant B can update it if they aren\u0027t admins? What\u0027s the use-case for this?","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"8a88fd809ddf87a0d97799245f37344614663ebb","unresolved":false,"context_lines":[{"line_number":65,"context_line":"delegating parts of an address scope to different tenants.  The SubnetPools"},{"line_number":66,"context_line":"under an AddressScope must not overlap.  They must also be from the same"},{"line_number":67,"context_line":"address family.  Only an admin can associate an AddressScope and SubnetPool"},{"line_number":68,"context_line":"from different tenants.  Once a subnet pool has been associated, it can only be"},{"line_number":69,"context_line":"updated by the address scope owner.  If this owner is not the subnet pool owner"},{"line_number":70,"context_line":"then it must be an admin."},{"line_number":71,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_c8e65d43","line":68,"in_reply_to":"3afb71cf_82b2af92","updated":"2015-06-10 17:54:18.000000000","message":"We could require that an admin can only associate to an scope owned by the admin.\n\nThe use case I had in mind is a subnet pool that is internet routable but should stay under the control of a single tenant.  Maybe the addresses belong to the tenant and are routed to the cloud on behalf of the tenant.\n\nI suspect that the majority of use cases will involve one subnet pool connected to one address scope, both owned by the same tenant.\n\nSo, maybe this isn\u0027t an important use case and we can just require that pools and scopes have the same owner.  In that case, an address scope adds little beyond a subnet pool.  I\u0027d like to hear more opinions on this before committing to the change.  It sounds like we\u0027re started to lean back toward conflating pools and scopes.  I recall that there was opposition to doing so.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"329280545a9bd38393d5a4feda8f43198383b2b5","unresolved":false,"context_lines":[{"line_number":70,"context_line":"then it must be an admin."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"A SubnetPool which is not associated with an AddressScope will be treated as if"},{"line_number":73,"context_line":"it were alone in its own address scope although no explicit address will be"},{"line_number":74,"context_line":"created for it."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"In the reference implementation of the L3 plugin, Neutron routers will be aware"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_82606f02","line":73,"updated":"2015-06-09 21:34:02.000000000","message":"\"no explicit address scope\"?","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"8a88fd809ddf87a0d97799245f37344614663ebb","unresolved":false,"context_lines":[{"line_number":70,"context_line":"then it must be an admin."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"A SubnetPool which is not associated with an AddressScope will be treated as if"},{"line_number":73,"context_line":"it were alone in its own address scope although no explicit address will be"},{"line_number":74,"context_line":"created for it."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"In the reference implementation of the L3 plugin, Neutron routers will be aware"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_f87a32f0","line":73,"in_reply_to":"3afb71cf_82606f02","updated":"2015-06-10 17:54:18.000000000","message":"Done","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"329280545a9bd38393d5a4feda8f43198383b2b5","unresolved":false,"context_lines":[{"line_number":74,"context_line":"created for it."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"In the reference implementation of the L3 plugin, Neutron routers will be aware"},{"line_number":77,"context_line":"of address scopes.  It will use multiple routing tables and policy routing --"},{"line_number":78,"context_line":"features found in Linux and managed by iproute2 -- to implement connecting to"},{"line_number":79,"context_line":"networks with different address scopes.  The incoming device (iif) will be"},{"line_number":80,"context_line":"specified with each rule."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_950b0724","line":77,"updated":"2015-06-09 21:34:02.000000000","message":"I\u0027m not sure I understand what the need for PBR is here. Is the implication that a single router can attach to multiple address scopes? If so, how does routing work between two overlapping networks?","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"8a88fd809ddf87a0d97799245f37344614663ebb","unresolved":false,"context_lines":[{"line_number":74,"context_line":"created for it."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"In the reference implementation of the L3 plugin, Neutron routers will be aware"},{"line_number":77,"context_line":"of address scopes.  It will use multiple routing tables and policy routing --"},{"line_number":78,"context_line":"features found in Linux and managed by iproute2 -- to implement connecting to"},{"line_number":79,"context_line":"networks with different address scopes.  The incoming device (iif) will be"},{"line_number":80,"context_line":"specified with each rule."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_b8803ac0","line":77,"in_reply_to":"3afb71cf_950b0724","updated":"2015-06-10 17:54:18.000000000","message":"Yes, a single router could attach to multiple scopes (explicitly stated on L79).  Otherwise, how would we NAT between scopes as you suggest?\n\nWith this proposal routing doesn\u0027t work between two overlapping networks.  If they are in the same scope then they don\u0027t overlap.  If they\u0027re not in the same scope then they don\u0027t route.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"329280545a9bd38393d5a4feda8f43198383b2b5","unresolved":false,"context_lines":[{"line_number":88,"context_line":""},{"line_number":89,"context_line":"NAT will be automatically included between an internal network and an"},{"line_number":90,"context_line":"\"external\" network to which a router is connected as a gateway *unless* the two"},{"line_number":91,"context_line":"networks have subnets from subnet pools in the same address scope.  It will"},{"line_number":92,"context_line":"provide 1-1 NAT for floating IPs and many-1 for default SNAT just like today."},{"line_number":93,"context_line":"This will support existing use cases.  We don\u0027t intend to implement any more"},{"line_number":94,"context_line":"NAT use cases than this at this time.  An addition (post-Liberty) may be a more"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_95f547ee","line":91,"updated":"2015-06-09 21:34:02.000000000","message":"Just to make sure I understand, this could be shortened to: \n\n\"as a gateway *unless* the two router interface addresses from the same address scope.\"","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"8a88fd809ddf87a0d97799245f37344614663ebb","unresolved":false,"context_lines":[{"line_number":88,"context_line":""},{"line_number":89,"context_line":"NAT will be automatically included between an internal network and an"},{"line_number":90,"context_line":"\"external\" network to which a router is connected as a gateway *unless* the two"},{"line_number":91,"context_line":"networks have subnets from subnet pools in the same address scope.  It will"},{"line_number":92,"context_line":"provide 1-1 NAT for floating IPs and many-1 for default SNAT just like today."},{"line_number":93,"context_line":"This will support existing use cases.  We don\u0027t intend to implement any more"},{"line_number":94,"context_line":"NAT use cases than this at this time.  An addition (post-Liberty) may be a more"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_b8cefa2a","line":91,"in_reply_to":"3afb71cf_95f547ee","updated":"2015-06-10 17:54:18.000000000","message":"Yes.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"329280545a9bd38393d5a4feda8f43198383b2b5","unresolved":false,"context_lines":[{"line_number":94,"context_line":"NAT use cases than this at this time.  An addition (post-Liberty) may be a more"},{"line_number":95,"context_line":"general ipv4 NAT functionality but we want to gauge the demand for that and"},{"line_number":96,"context_line":"explore other options too, like providing something as part of LBaaS or"},{"line_number":97,"context_line":"something like that."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":".. image:: ../../images/address-scopes.png"},{"line_number":100,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_b5da8349","line":97,"updated":"2015-06-09 21:34:02.000000000","message":"I really think this is our opportunity to clean up a lot of the external network special-casing. Why not just generalize it to: \"Any time a router it attached to different address scopes, NAT will be performed between the address scopes\"?\n\nThen the only thing an external network would really mean is that floating IPs can be allocated from it and that it should be used as the default gateway for the router. The NAT would become implicit because of the different scopes.\n\nOr is there some use-case using PBR on the tenant routers between scopes that I didn\u0027t understand?","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"8a88fd809ddf87a0d97799245f37344614663ebb","unresolved":false,"context_lines":[{"line_number":94,"context_line":"NAT use cases than this at this time.  An addition (post-Liberty) may be a more"},{"line_number":95,"context_line":"general ipv4 NAT functionality but we want to gauge the demand for that and"},{"line_number":96,"context_line":"explore other options too, like providing something as part of LBaaS or"},{"line_number":97,"context_line":"something like that."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":".. image:: ../../images/address-scopes.png"},{"line_number":100,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_f896b2ee","line":97,"in_reply_to":"3afb71cf_b5da8349","updated":"2015-06-10 17:54:18.000000000","message":"I\u0027ve had exactly that in mind.  I think you and I have agreed in the past on the fact that the external network concept is kind of strange and we should break it down in to more generic properties.\n\nBut I think it makes the scope of this work larger.  It begs many more questions:  What about ipv6?  What kind of nat?  Do we just do many to one nat with the router\u0027s address?  Do we allow creating floating IPs from any network or do we have a flag on the network to indicate that we can create floating ips?  What will this do to DVR if many to one NAT is used?  What if I don\u0027t want to route between two particular scopes?\n\nI\u0027m trying to crawl here and you\u0027re asking me to get up and walk.  :)","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":6659,"name":"Paul Michali","email":"pc@michali.net","username":"pcm"},"change_message_id":"7a5d3c1866cd6ccc7ff4288d51625c0bba6ac9c9","unresolved":false,"context_lines":[{"line_number":228,"context_line":""},{"line_number":229,"context_line":"There is also work to introduce VRF capability in to the Linux kernel directly"},{"line_number":230,"context_line":"[#]_.  This work could provide richer capability.  However, it is very new and"},{"line_number":231,"context_line":"isn\u0027t ready to be used for this purpose."},{"line_number":232,"context_line":""},{"line_number":233,"context_line":".. [#] https://lwn.net/Articles/632522/"},{"line_number":234,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"5afe65bd_b2ebd912","line":231,"updated":"2015-06-04 12:42:50.000000000","message":"It sounds like modeling the current work along the lines of VRFs may make a transition to VRFs easier int he future.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"2efe60c256859dd3d04bfe38f3092b0040dc2070","unresolved":false,"context_lines":[{"line_number":228,"context_line":""},{"line_number":229,"context_line":"There is also work to introduce VRF capability in to the Linux kernel directly"},{"line_number":230,"context_line":"[#]_.  This work could provide richer capability.  However, it is very new and"},{"line_number":231,"context_line":"isn\u0027t ready to be used for this purpose."},{"line_number":232,"context_line":""},{"line_number":233,"context_line":".. [#] https://lwn.net/Articles/632522/"},{"line_number":234,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3afb71cf_a89f4c5e","line":231,"in_reply_to":"5afe65bd_b2ebd912","updated":"2015-06-05 18:28:56.000000000","message":"Good point.  I think this design is consistent with what we might be able to do in the future with VRFs in the future.  We\u0027ll have to continue to evaluate the progress of that work and its suitability for this application.","commit_id":"a7096fdd2d18e8ca4d3887d4347dc930ee2b5c60"},{"author":{"_account_id":17609,"name":"steve","email":"ruansx@cn.ibm.com","username":"steve.ruan"},"change_message_id":"ed2ecdd351066b462d8a6d4066fc9d60ee9cdcda","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":"In the reference implementation of the L3 plugin, Neutron routers will be aware"},{"line_number":76,"context_line":"of address scopes.  It will use multiple routing tables and policy routing --"},{"line_number":77,"context_line":"features found in Linux and managed by iproute2 -- to implement connecting to"},{"line_number":78,"context_line":"networks with different address scopes.  The incoming device (iif) will be"},{"line_number":79,"context_line":"specified with each rule."},{"line_number":80,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"da85f559_d232f45e","line":77,"updated":"2015-11-11 02:43:36.000000000","message":"I did not understand why neutron router need be aware of address scope. Each neutron router has its own namespace which means each neutron router represent a L3 VPN. \nIf a tenant has networks in more than 2 address scope, the address may be overlapped, traffic between them can not be routed directly by a single router.\nWhy not create a router for each address scope?","commit_id":"fb18cf6657ff9cdf8d632ca2e0d9559cd2a14b96"},{"author":{"_account_id":17609,"name":"steve","email":"ruansx@cn.ibm.com","username":"steve.ruan"},"change_message_id":"ed2ecdd351066b462d8a6d4066fc9d60ee9cdcda","unresolved":false,"context_lines":[{"line_number":97,"context_line":""},{"line_number":98,"context_line":".. image:: ../../images/address-scopes.png"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Routers will route between networks of the same scope without NAT.  For"},{"line_number":101,"context_line":"example, if a tenant has a subnet pool and the admin includes that subnet pool"},{"line_number":102,"context_line":"in the same address scope as the external network then that tenant\u0027s subnets"},{"line_number":103,"context_line":"will be routed directly to the external network."}],"source_content_type":"text/x-rst","patch_set":9,"id":"da85f559_d2519437","line":100,"updated":"2015-11-11 02:43:36.000000000","message":"2 networks in 2 tenants, and their subnets in same address scope. How they can route traffic directly? Each tenants will have its owner neutron router, suppose their name is R1 and R2, will R1 have a interface connect to R2? How this will happen?","commit_id":"fb18cf6657ff9cdf8d632ca2e0d9559cd2a14b96"},{"author":{"_account_id":18855,"name":"Siddanagouda Khot","email":"siddanmk@yahoo.co.in","username":"siddanmk"},"change_message_id":"e4f5b7edea9cec016d2644ca00463244e1cc3620","unresolved":false,"context_lines":[{"line_number":120,"context_line":"#. Adds a new field (default null) to the SubnetPool referencing a single"},{"line_number":121,"context_line":"   AddressScope.  This will be updatable.  On update, the subnet pool will be"},{"line_number":122,"context_line":"   checked for address uniqueness with other subnet pools under the scope."},{"line_number":123,"context_line":"   Also, routers must be notified of the change in order to adjust routing."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":".. TODO Carl Any association with RTs and RDs, etc?  I\u0027m thinking that could be"},{"line_number":126,"context_line":"   developed when dynamic routing is integrated later in Liberty but maybe we"}],"source_content_type":"text/x-rst","patch_set":9,"id":"da85f559_40542a20","line":123,"updated":"2015-11-12 23:36:01.000000000","message":"If there will be multiple routing tables based on address scopes  on a router, how is the association of address scopes with routing tables? As in, one routing table per address scope id? Need more explanation/clarity.","commit_id":"fb18cf6657ff9cdf8d632ca2e0d9559cd2a14b96"},{"author":{"_account_id":17455,"name":"Na Zhu","email":"juno.zhu@huawei.com","username":"Na"},"change_message_id":"94f7fddf451c56707a8c1d3500e541a36de92a04","unresolved":false,"context_lines":[{"line_number":125,"context_line":".. TODO Carl Any association with RTs and RDs, etc?  I\u0027m thinking that could be"},{"line_number":126,"context_line":"   developed when dynamic routing is integrated later in Liberty but maybe we"},{"line_number":127,"context_line":"   need to flesh this out here."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"REST API Impact"},{"line_number":130,"context_line":"---------------"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"da85f559_ebb89fc9","line":128,"updated":"2015-11-15 12:21:03.000000000","message":"There must be some conflict checking, right?\nsuch as the networks behind one router must be in different address scope, can you depict all the conflict checking here?","commit_id":"fb18cf6657ff9cdf8d632ca2e0d9559cd2a14b96"}]}