<div dir="ltr">Hello Stackers!<div><br></div><div>I agree with "one namespace approach", if it is better for IPv6 (or even for IPv4 and for operators).</div><div><br></div><div>And also, I think that, when with IPv6, we must do what is better for IPv6 networks... If things needs to be changed, lets do it!</div>
<div><br></div><div>BTW, one namespace with all the required services on it, makes more sense to me either, this way, OpenStack can focus on "namespace = tenant router", with dhcp, dhcpv6, RA, filter, IPv4 NAT, etc, on it... Just like a "real world router"... OpenStack approach to present the Linux Namespace as a router to tenants is awesome by itself!</div>
<div><br></div><div>Operators can learn the new way of doing things, now with IPv6, it can be simpler! No NAT tables, pure routing, less namespaces to deal with, VXLAN seems to work better when with IPv6 (nephos6 PDF have some notes about it)...</div>
<div> </div><div>I'm wondering about starting millions of tiny Docker Instances, each one with its own public IPv6 address! This will be epic! :-D</div><div><br></div><div>What about a Floating IP for IPv6?! I think we can provide a "IPv6 Floating IP" (without any kind NAT, of course), so, this "Floating IPv6" address will appear <b><u>within</u></b> the attached Instance, instead of within its namespace router, as it is with IPv4 (a NAT rule at the namespace router). What do you guys think about this idea? This way, the namespace router will be used to configure/deliver more IPv6 address for each Instance.</div>
<div> </div><div>Another idea is: the Tenant IPv6 Namespace Router should provide a way (I think), to deliver a range of IPv6 address (if possible), not only 1 per Instance. This way, a Instance can have hundreds of web sites (Apache, NGinx), each one with its own public IP (I prefer this Apache setup: <a href="http://httpd.apache.org/docs/2.2/vhosts/ip-based.html">IP-Based</a>), because I really like the idea of 1 public IP for each website, but not 1 Instance for each website (perhaps with Docker it will be okay to have 1 Instance per website).</div>
<div><br></div><div>Sorry to throw lots of subjects, I don't want to hijack the thread but, the namespaces does lots of things anyway... =P</div><div><br></div><div>NOTE: Can I start testing IPv6 tenant networks with Neutron 2014.1~b1 from Ubuntu 14.04?!</div>
<div><br></div><div>Cheers!</div><div>Thiago</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 19 December 2013 23:31, Shixiong Shang <span dir="ltr"><<a href="mailto:sparkofwisdom.cloud@gmail.com" target="_blank">sparkofwisdom.cloud@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi, Ian:<div><br></div><div>The use case brought by Comcast team today during the ipv6 sub-team meeting actually proved the point I made here, instead of against it. If I didn’t explain it clearly in my previous email, here it is.</div>
<div><br></div><div>I was questioning the design with two namespaces and I believe we can use a SINGLE namespace as the common container to host two services, i.e. DHCP and ROUTING. If your use case needs DHCP instance, but not ROUTING, then just launch dnsmasq in THE namespace with qr- interface; If your use case needs default GW, then add qg- interface in THE namespace. Whether it is called qdhcp or qrouter, I don’t care. It is just a label. </div>
<div><br></div><div>People follow the routine to use it, simply because this is what OpenStack offers. But my question is, why? And why NOT we design the system in the way that qg- and qr- interface collocate in the same namespace?</div>
<div><br></div><div>It is because we intentionally separate the service, now the system become clumsy and less efficient. As you can see in IPv6 cases, we are forced to deal with two namespaces now. It just doesn’t make any sense.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>Shixiong</div></font></span><div><div class="h5"><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><div>On Dec 19, 2013, at 7:27 PM, Ian Wells <<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div>Per the discussions this evening, we did identify a reason why you might need a dhcp namespace for v6 - because networks don't actually have to have routers. It's clear you need an agent in the router namespace for RAs and another one in the DHCP namespace for when the network's not connected to a router, though. <br>
<br>We've not pinned down all the API details yet, but the plan is to implement an RA agent first, responding to subnets that router is attached to (which is very close to what Randy and Shixiong have already done).<br>
-- <br></div>Ian.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 19 December 2013 14:01, Randy Tuttle <span dir="ltr"><<a href="mailto:randy.m.tuttle@gmail.com" target="_blank">randy.m.tuttle@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>First, dnsmasq is not being "moved". Instead, it's a different instance for the attached subnet in the qrouter namespace. If it's not in the qrouter namespace, the default gateway (the local router interface) will be the interface of qdhcp namespace interface. That will cause blackhole for traffic from VM. As you know, routing tables and NAT all occur in qrouter namespace. So we want the RA to contain the local interface as default gateway in qrouter namespace</div>
<div><br></div><div>Randy<br><br>Sent from my iPhone</div><div><br>On Dec 19, 2013, at 4:05 AM, Xuhan Peng <<a href="mailto:pengxuhan@gmail.com" target="_blank">pengxuhan@gmail.com</a>> wrote:<br><br>
</div><div><div><blockquote type="cite"><div dir="ltr"><div><div><div><div>I am reading through the blueprint created by Randy to bind dnsmasq into qrouter- namespace:<br><br><a href="https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace" target="_blank">https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace</a><br>
<br></div>I don't think I can follow the reason that we need to change the namespace which contains dnsmasq process and the device it listens to from qdhcp- to qrouter-. Why the original namespace design conflicts with the Router Advertisement sending from dnsmasq for SLAAC?<br>
<br></div>From the attached POC result link, the reason is stated as:<br><br>"Even if the dnsmasq process could send Router Advertisement, the default gateway would bind to its own link-local address in the qdhcp- namespace. As a result, traffic leaving tenant network will be drawn to DHCP interface, instead of gateway port on router. That is not desirable! "<br>
<br></div>Can Randy or Shixiong explain this more? Thanks!<br><br></div>Xuhan <br></div>
</blockquote></div></div><blockquote type="cite"><span>_______________________________________________</span><div><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></span><br>
<span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>