Hi, Randy: Thanks a bunch for pointing it out! Yup, you are absolutely right. What I wanted to say is why not put qg-, qr-, and ns- interfaces in the single namespace.
I typed it on my small keyboard on iPhone. Sorry for the confusion. :( Shixiong On Dec 19, 2013, at 8:44 PM, Randy Tuttle <[email protected]> wrote: > Shixiong, > > I know you must have a typo in the 3rd paragraph. I think maybe you mean to > include the ns- interface in that list. So why not have qg- qr- and ns- > interfaces in the same namespace. Am I right? > > Rnady > > > On Thu, Dec 19, 2013 at 8:31 PM, Shixiong Shang > <[email protected]> wrote: > Hi, Ian: > > 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. > > 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. > > 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? > > 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. > > Shixiong > > > > > > > On Dec 19, 2013, at 7:27 PM, Ian Wells <[email protected]> wrote: > >> 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. >> >> 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). >> -- >> Ian. >> >> >> On 19 December 2013 14:01, Randy Tuttle <[email protected]> wrote: >> 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 >> >> Randy >> >> Sent from my iPhone >> >> On Dec 19, 2013, at 4:05 AM, Xuhan Peng <[email protected]> wrote: >> >>> I am reading through the blueprint created by Randy to bind dnsmasq into >>> qrouter- namespace: >>> >>> https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace >>> >>> 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? >>> >>> From the attached POC result link, the reason is stated as: >>> >>> "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! " >>> >>> Can Randy or Shixiong explain this more? Thanks! >>> >>> Xuhan >>> _______________________________________________ >>> >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
