Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the write-up! See inline.

On 02/13/2015 04:34 PM, Robert Li (baoli) wrote:
> Hi,
> 
> while trying to integrate dibbler client with neutron to support
> PD, we countered a few issues with the dibbler client (and server).
> With a neutron router, we have the qg-xxx interface that is
> connected to the public network, on which a dhcp server is running
> on the delegating router. For each subnet with PD enabled, a router
> port will be created in the neutron router. As a result, a new PD
> request will be sent that asks for a prefix from the delegating
> router. Keep in mind that the subnet is added into the router
> dynamically.
> 
> We thought about the following options:
> 
> 1. use a single dibbler client to support the above requirement.
> This means, the client should be able to accept new requests on the
> fly either through configuration reload or other interfaces. 
> Unfortunately, dibbler client doesn’t support it.

Sorry for my ignorance on PD implementation (I will definitely look at
it the next week), but what does this entry above mean? Do you want a
single dibbler instance running per router serving all subnets plugged
into it? And you want to get configuration updates when a new subnet
is plugged in, or removed from the router?

If that's the case, why not just restarting the client?

> 2. start a dibbler client per subnet. All of the dibbler clients
> will be using the same outgoing interface (which is the qg-xxx 
> interface). Unfortunately, dibbler client uses /etc/dibbler and 
> /var/lib/dibbler for its state (in which it saves duid file, pid 
> file, and other internal states). This means it can only support
> one client per network node. 3. run a single dibbler client that
> requests a smaller prefix (say /56) and splits it among the subnets
> with PD enabled (neutron subnet requires /64). Depending on the
> neutron router setup, this may result in significant waste of
> prefixes.

Just to understand all options at the table: can we implement ^^
option with stock dibbler?

> 
> Given the significant drawback with 3, we are left with 1 and 2.
> After looking at the dibbler source code, we found that 2 is easier
> to achieve for now by making some small changes in the dibbler
> code. In the long run, we think option 1 is better.
> 
> The changes we made to the linux dibbler client code, and the
> dibbler server code can be found in here: 
> https://github.com/johndavidge/dibbler/tree/cloud-dibbler.
> Basically it does a few things: — create a unique working area per
> dibbler client — since all the clients use the same outgoing
> interface, we’d like each dibbler client to use a unique LLA as its
> source address when sending messages. This would avoid clients to
> receive server messages that are not intended for them. — we found
> that dibbler server uses transaction ID alone to identify a match
> between a request and an answer. This would require that unique 
> transaction IDs be used among all the existing clients. We found
> that clients could use the same transaction IDs in our
> environment. Therefore, a little change is made in the server code
> so that it will take the request sender into consideration while
> looking up a match.
> 
> 
> Option 1 requires better understanding of the dibbler code, and we
> think that it may not be possible to make it happen in the kilo
> timeframe. But we think it has significant advantages over option
> 2. Regardless, changes made for 2 is also needed since we need to
> run one dibbler client per neutron router.
> 
> Now the issue is how to make those changes (possible with further 
> revision) into an official dibbler release ASAP so that we can use
> them for kilo release. John Davidge has contacted the dibbler
> authors, and hasn’t received response so far.

That's disturbing from packager point of view.

- From Red Hat side, we miss dibbler packaged in Fedora, but that's a
minor issue, we can easily put some effort and do it.

As for shipping side patches with it, it's a major problem. Especially
considering the fact that those patches were not reviewed or accepted
by dibbler upstream.

I think it is critical to reach dibbler authors ASAP and see what they
have to say about these patches. Remember, we're in Kilo-3 mode already.

Reading thru the spec [1], it seems to me that dibbler won't be
involved at all unless users explicitly omit prefix info when creating
subnets. Is it correct? If so, can we somehow provide an easy way for
distributions and deployers out of using custom patched dibbler by
disabling the feature completely if/when they see shipping this
version of dibbler unacceptable? I think we could introduce a new
config option that would forbid prefix delegated subnets (?).

Speaking of deployers, have you also considered providing a patch for
sanity_check tool that would test local dibbler installation on
whether it supports the needed features?

Also, on a relevant note, how do you test the feature in gate? Distro
packages probably don't ship the patched version of the client. Do you
have any functional tests that utilize the client?

[1]:
https://github.com/openstack/neutron-specs/blob/master/specs/kilo/ipv6-prefix-delegation.rst

/Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEbBAEBAgAGBQJU3h/vAAoJEC5aWaUY1u57f4gH8wWTMvYdIVwjJL9QjF9YTjMd
AMEJZcBN7nAYcjsI8Oxx5rxYs4uKV8QA/RD0Cy2JhweQV0GdjtZMxxh2gt2rRF5E
pV/kRsiQsyJFlaWgsnWccZ1IxXHHLufUbcqkW7+XMzLQ+T+xZfUllwxUBsWzZcR2
nzedsSsF3wdIU7yw9iYp8iXiVLtHD0Ryq6dAJXiX15amWg46f1cDCcxhnIMJflCR
AET+QR9QYzUSFgpMKmmab0VrGzyeWpqJ+lvVpFhhO+y5Iap7HsOZpAGwaUBihlui
lnOD7223Ueqw9UQVo8JFSDh3tlwC8dP7mfEHK45DAvfkFdVJkk+w7PKzauUXhQ==
=WdfD
-----END PGP SIGNATURE-----