Hello Stackers!
I agree with "one namespace approach", if it is better for IPv6 (or even
for IPv4 and for operators).
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!
BTW, one namespace with all the required service
ts.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter-
namespace
Interesting. So you're suggesting we provision a single namespace (per
network, rather than subnet?) proactively, and use it for both routing and
DHCP. Not unreasonable. Als
Interesting. So you're suggesting we provision a single namespace (per
network, rather than subnet?) proactively, and use it for both routing and
DHCP. Not unreasonable. Also workable for v4, I think?
--
Ian.
On 20 December 2013 02:31, Shixiong Shang wrote:
> Hi, Ian:
>
> The use case brough
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
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> wrot
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
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
Hi, Xuhan:
Thanks for reaching out to us for questions! Here are the summary of several
key points:
1. Currently dnsmasq is bound to the ns- interface within qdhcp- namespace. If
we continue to use this model, then the announced RA has to use the ns-
interface’s link-local address as source, b
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 traff
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
10 matches
Mail list logo
