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 < sparkofwisdom.cl...@gmail.com> 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 <ijw.ubu...@cack.org.uk> 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 <randy.m.tut...@gmail.com> 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 <pengxu...@gmail.com> 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 >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
