On Tue, Aug 29, 2017 at 3:15 PM Brian Haley <haleyb....@gmail.com> wrote:
> Sorry for the slow review, was on PTO. Comments below. > > On 08/22/2017 05:43 PM, Mark Michelson wrote: > > Hi folks, > > > > For a while now, in a "learn the OVN project from scratch" project, I've > > been investigating what it would take in order to allow for OVN to send > > periodic router advertisements (RAs) as part of a greater goal of > rounding > > out IPv6 support. I've had some discussions about individual parts of > this > > with various people, and now I want to come forward with an actual > proposal > > of how I envision accomplishing this. > > > > First, let's start with what an RA is. It is an ICMPv6 message that a > > router sends out in order to say "I am a router" to any other nodes on a > > link. Beyond that, an RA may contain information such as MTU, supported > > IPv6 prefixes, hop count, and other useful information about the router > > interface. The RA can be sent for one of two reasons: > > > > 1) A host on the link has sent a router solicitation (RS) message, and > the > > router is responding directly to that. > > 2) The router can be configured to periodically send RAs to all nodes on > > the link. > > > > For (1), Numan Siddique currently has a set of patches up for review that > > adds this support. I am attempting to add (2). > > > > My primary goal here is determining how to configure ovn-controllers to > > know to periodically send RAs, and to ensure they have the necessary > > information to do so. The rest of this e-mail details how I propose to do > > that. > > > > There is a patch[1] currently up for consideration that adds a new column > > to the northbound Logical_Router_Port table called ipv6_ra_configs. This > > currently only has two configurable options: > > * address_mode > > I'm assuming that based on the mode that certain RA flags will be > enabled? Maybe this was covered in Numan's change, haven't taken a look > there. For example, with stateful the M flag is set. > Thanks for the feedback. Numan's change sets the M and O flags based on the configured ipv6_ra_configs address_mode. If set to "dhcp_stateful", then the M flag is set. If set to "dhcp_stateless", then the O flag is set. I plan to do the same thing with the periodic RAs. > > > * mtu > > In order to allow periodic router advertisements, I propose the following > > options to be added to the ipv6_ra_configs > > * send_periodic - boolean indicating if periodic RAs should be sent. > > Defaults to false > > * max_interval - integer indicating the maximum number of seconds to wait > > between sending periodic RAs. Defaults to 600 seconds. > > * max_interval - integer indicating the minimum number of seconds to wait > > between sending periodic RAs. Defaults to 0.33 * max_interval (200 > seconds > > if max_interval is set to its default). > > For min_interval (typo), I would just follow what the RFC says and not > only do 0.33 if max_interval is at its default: > > Default: 0.33 * MaxRtrAdvInterval If > MaxRtrAdvInterval >= 9 seconds; otherwise, the > Default is MaxRtrAdvInterval. > > Looks good otherwise. > Oops, Sorry about the typo. I'll be sure to follow the RFC for the minimum calculation. > -Brian > > > This is the minimum requirement. RFC 4861 defines many other > configuration > > options that will alter the contents of RAs, but those can be added in a > > future update if necessary. > > > > If someone wishes to periodically send RAs, they can set the > send_periodic > > northbound value true and adjust the interval to their liking. > ovn-northd, > > upon seeing that the send_periodic is set true, will copy the entirety of > > the ipv6_ra_configs column into the options column of the corresponding > > Port_Binding entry of the southbound database. To scope these as IPv6 RA > > options, the keys in the southbound database will be prepended with > > ipv6_ra_. So for instance, when copying the "address_mode" from the > > northbound database, it would become "ipv6_ra_address_mode" in the > > southbound database. In addition to the contents of the northbound > > Logical_Router_Port ipv6_ra_configs, ovn-northd will insert data about > the > > RAs themselves, such as the network prefixes to be advertised (learned > from > > the logical router port's networks) and the source ethernet and IP > > addresses to use in RAs. > > > > Example: > > I create a logical router port as follows: > > ovn-nbctl lrp-add lr0 lr0-p0 00:11:22:33:44:55 2001:db8::1/64 > > I then modify the logical router port's ipv6_ra_configs as follows: > > ovn-nbctl set Logical_Router_Port lr0-p0 > > ipv6_ra_config:send_periodic=true > > When northd runs, it will populate the southbound database's Port_Binding > > for lr0-p0 as follows: > > options: {ipv6_ra_send_periodic=true, > > ipv6_ra_src_mac=00:11:22:33:44:55, ipv6_ra_src_addr=2001:db8::1, > > ipv6_ra_prefixes=2001:db8::/64} > > > > ovn-controller already has code that determines which datapaths are local > > to the chassis. With these datapaths found, we can add code to make > > ovn-controller iterate over the port bindings that pertain to that > > datapath. If any port bindings have ipv6_ra_send_periodic=true in their > > options, then the ovn-controller needs to send out periodic RAs. > > > > The sending of RAs will closely mirror the method by which ovn-controller > > currently sends gratuitous ARP packets. That is, a structure will be > > allocated that contains all the necessary information about what to send > in > > the outgoing RA, plus information on when the next RA should be sent out. > > Handling of when to send out RAs will be handled similarly to gratuitous > > ARPs as well, except that instead of having a backoff timer, the interval > > will be recalculated each time based on the configuration. > > > > If you've made it this far in the e-mail, then thank you! If you have any > > suggestions for other methods of doing this or have any questions about > any > > part of the proposed process, please let me know. > > > > Mark Michelson > > > > [1] https://patchwork.ozlabs.org/patch/804391/ > > _______________________________________________ > > dev mailing list > > d...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev