I created a new PDF file to show two parameters (i.e. not referring “enable_dhcp”). Here is the link. I also updated BP too.
https://www.dropbox.com/s/rq8xmbruqthef38/IPv6%20Two%20Modes%20v2.0.pdf Shixiong On Jan 21, 2014, at 6:31 PM, Shixiong Shang <sparkofwisdom.cl...@gmail.com> wrote: > Hi, Anthony: > > I think we are saying the same thing. Yes, there must be two parameters, and > they are independent. What I mean of "simplifying" referred to the CLI. If > user provides RA mode, then the 2nd parameter will have default value if user > doesn't specify it. However, user can also indicate different value > explicitly. > > The use cases you pointed out are also called out in the table attached to > the end of the email. Anything caught your eyes? > > Thanks, Anthony! > > Shixiong > > > > > > On Jan 21, 2014, at 4:46 PM, "Veiga, Anthony" > <anthony_ve...@cable.comcast.com> wrote: > >> >> Hi, Sean and Xuhan: >> >> I totally agree. This is not the ultimate solution with the assumption that >> we had to use “enable_dhcp”. >> >> We haven’t decided the name of another parameter, however, we are open to >> any suggestions. As we mentioned during the meeting, the second parameter >> should highlight the need of addressing. If so, it should have at least four >> values: >> >> 1) off (i.e. address is assigned by external devices out of OpenStack >> control) >> 2) slaac (i.e. address is calculated based on RA sent by OpenStack dnsmasq) >> 3) dhcpv6-stateful (i.e. address is obtained from OpenStack dnsmasq acting >> as DHCPv6 stateful server) >> 4) dhcpv6-stateless (i.e. address is calculated based on RA sent from either >> OpenStack dnsmasq, or external router, and optional information is retrieved >> from OpenStack dnsmasq acting as DHCPv6 stateless server) >> >> This I agree with. >> >> >> In other words, the original “on” mode captured in “enable_dhcp" should >> provide more granularity. Since the bits in RA will trigger VM to take >> certain actions (calculate address, solicit DHCPv6, etc.), I think we can >> simplify it by saying, if OpenStack RA Mode is >> slacc/dhcpv6-stateful/dhcpv6-stateless, then by default, the 2nd parameters >> shares the same value. >> >> Absolutely not. The reason for separating routing and addressing is because >> you can't assume that because one piece is present, that the other is too. >> If I want OpenStack to assign addresses via DHCPv6, then I set the >> addressing parameter to stateful. But maybe I want the RA to come from my >> provider network router. In that case, the RA mode is OFF. We MUST >> separate these, as there are other permutations as well. >> >> >> Thanks! >> >> Shixiong >> >> >> >> <PastedGraphic-1.png> >> >> >> >> >> >> >> On Jan 21, 2014, at 10:42 AM, Xuhan Peng <pengxu...@gmail.com> wrote: >> >>> I think what will confuse openstack end user/admin will be the difference >>> between the combination of "RA mode=slaac, enable_dhcp=off" and "RA >>> mode=dhcpv6_stateless, enable_dhcp=off". The only difference will be if >>> getting optional info from external DHCPv6 server using DHCPv6 stateless >>> but it's hard to tell from the RA mode unless the admin is very familiar >>> with dnsmasq. I think we are trying to isolate the detail of dnsmasq >>> configuration from the API attribute here based on our previous discussion, >>> but I could not figure out a better mode name here too. >>> >>> Just want to point out this before going to bed. Will be back tomorrow and >>> check on other ones' input on this. >>> >>> >>> On Tue, Jan 21, 2014 at 10:07 PM, Shixiong Shang >>> <sparkofwisdom.cl...@gmail.com> wrote: >>> >>> >>> Begin forwarded message: >>> >>>> From: Shixiong Shang <sparkofwisdom.cl...@gmail.com> >>>> Subject: Re: Cannot make it today at 4pm EST >>>> Date: January 17, 2014 at 3:09:56 PM EST >>>> To: "Veiga, Anthony" <anthony_ve...@cable.comcast.com> >>>> Cc: "Ian Wells (iawells)" <iawe...@cisco.com> >>>> >>>> Hi, Anthony and Ian: >>>> >>>> Not sure how the API discussion is going with Neutron team. Please let me >>>> know what I can help from my side. >>>> >>>> Last night, I put together this slide to summarize the possible >>>> combinations of RA mode and “enable_dhcp” keyword. It is quite clear that >>>> the current on/off boolean value won’t be sufficient. However, I think it >>>> is still possible to support this pair of keywords within IceHouse >>>> timeline while negotiating with Neutron team for more flexible approach in >>>> the next major release. >>>> >>>> If you are thinking along the same line, would you please let me know what >>>> I overlooked? >>>> >>>> Thanks! >>>> >>>> Shixiong >>>> >>>> >>>> >>>> <PastedGraphic-1.png> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Jan 14, 2014, at 4:47 PM, Veiga, Anthony >>>> <anthony_ve...@cable.comcast.com> wrote: >>>> >>>>> >>>>> >>>>>> OK, I see that we're back to splitting the RA and DHCP modes, though I'm >>>>>> not sure why - enable_dhcp is bugger all use for anything other than a >>>>>> flat-out disable flag, since it's a boolean, so it's not like we can >>>>>> make much use of it. Otherwise are we talking about whether we have an >>>>>> external router and/or DHCP server? >>>>> >>>>> >>>>> Precisely this. We determined multiple times previously that there is a >>>>> chance of either of these items being external to OpenStack. Where >>>>> appropriate, we need to also be able to get out of the way. >>>>> >>>>>> -- >>>>>> Ian. >>>>>> >>>>>> >>>>>> From: <Veiga>, Anthony <anthony_ve...@cable.comcast.com> >>>>>> Date: Tuesday, 14 January 2014 21:34 >>>>>> To: Ian Wells <iawe...@cisco.com>, Shixiong Shang >>>>>> <sparkofwisdom.cl...@gmail.com> >>>>>> Subject: Re: Cannot make it today at 4pm EST >>>>>> >>>>>>> You missed the first part of the meeting this morning. Addressing >>>>>>> should be either off, stateful or stateless and routing should be the 4 >>>>>>> modes. If enable_dhcp is there, then it's boolean and cuts off our >>>>>>> stateful/stateless determination. Unless you think we should provide >>>>>>> everything to dnsmasq and hope the clients are smart enough to only >>>>>>> send the options flag? >>>>>>> >>>>>>>> I don't think so. >>>>>>>> >>>>>>>> Given the two attrs below we have 6 permutations of values. Three of >>>>>>>> those are simply 'off'. The other three are our three settings that >>>>>>>> weren't 'off'. We monitor changes to either value. >>>>>>>> >>>>>>>> What are you seeing that I'm not? >>>>>>>> -- >>>>>>>> Ian. >>>>>>>> >>>>>>>> >>>>>>>> From: <Veiga>, Anthony <anthony_ve...@cable.comcast.com> >>>>>>>> Date: Tuesday, 14 January 2014 21:28 >>>>>>>> To: Ian Wells <iawe...@cisco.com>, Shixiong Shang >>>>>>>> <sparkofwisdom.cl...@gmail.com> >>>>>>>> Subject: Re: Cannot make it today at 4pm EST >>>>>>>> >>>>>>>>> So now we need 3 attributes. One is enable_dhcp, one is dhcp_mode, >>>>>>>>> and one is ra_mode. We can't do permutations, because some of them >>>>>>>>> would be dependent on enable_dhcp, which our routines would no longer >>>>>>>>> control. >>>>>>>>> >>>>>>>>> >>>>>>>>>> OK, I tracked Mark down and asked about what he was on with. I'm >>>>>>>>>> not saying I like the result of it though. >>>>>>>>>> >>>>>>>>>> The point they're making is that enable_dhcp exists on a v6 subnet >>>>>>>>>> and should enable or disable DHCP if no-one touches anything else >>>>>>>>>> there, because that's what it used to do (and apparently it even >>>>>>>>>> worked with NVP). So instead of one value, we need two: >>>>>>>>>> >>>>>>>>>> enable_dhcp = false (our 'off') or true (anything else) >>>>>>>>>> ipv6_addr_mode = slaac, dhcpv6-stateless, dhcpv6-stateful (which, >>>>>>>>>> because it was the default in the old world, wants to remain as DHCP >>>>>>>>>> providing the address as default in the new one) - obviously if >>>>>>>>>> enable_dhcp is off this is ignored. >>>>>>>>>> >>>>>>>>>> It's a matter of API compatibility so they're not going to move on >>>>>>>>>> this. It's not as nice as what we had but it's what we have to do, >>>>>>>>>> I think. >>>>>>>>>> -- >>>>>>>>>> Ian. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From: <Veiga>, Anthony <anthony_ve...@cable.comcast.com> >>>>>>>>>> Date: Monday, 13 January 2014 23:48 >>>>>>>>>> To: Ian Wells <iawe...@cisco.com>, Shixiong Shang >>>>>>>>>> <sparkofwisdom.cl...@gmail.com> >>>>>>>>>> Subject: Re: Cannot make it today at 4pm EST >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> See below. >>>>>>>>>>>>>> I am curios as to why stateless is the default. Shouldn't SLAAC >>>>>>>>>>>>>> be default for all /64's and stateless be default for everything >>>>>>>>>>>>>> else? >>>>>>>>>>>>> >>>>>>>>>>>>> [SHSHANG] I like this proposal better. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If nothing lese stateless in all cases is easier to document. In >>>>>>>>>>>> the (perhaps unlikely) event that things work in all cases >>>>>>>>>>>> stateless is more flexible, too. >>>>>>>>>>>> >>>>>>>>>>>>>> Just to be ABSOLUTELY, 100% CLEAR, this section is for the RA >>>>>>>>>>>>>> definition only, correct? I want to make sure we're still >>>>>>>>>>>>>> decoupling the RA configuration and the Addressing >>>>>>>>>>>>>> configuration. There are still use cases for OpenStack >>>>>>>>>>>>>> provisioning via DHCPv6, but the router being an external >>>>>>>>>>>>>> device. We absolutely have to decouple these. >>>>>>>>>>>>> >>>>>>>>>>>>> [SHSHANG] Good point. In your case, can user adopt “off” mode, so >>>>>>>>>>>>> external router will send RA to trigger VM provisioning with >>>>>>>>>>>>> DHCPv6? In case that OpenStack Neutron router sending RA and VM >>>>>>>>>>>>> provisioning with DHCPv6 (via dnsmasq), then user can use our >>>>>>>>>>>>> dhcpv6-stateful and dhcpv6-stateless. >>>>>>>>>>>>> >>>>>>>>>>>>> Currently the way I coded the dhcp client is, if user choose >>>>>>>>>>>>> dhcpv6-stateful or dhcpv6-stateless, the dnsmasq also acts as >>>>>>>>>>>>> DHCPv6 server for the subnet. This behavior should not conflict >>>>>>>>>>>>> with the case as you mentioned previously. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If the gateway is set and there's no router attached then the >>>>>>>>>>>> external router would be expected to provide the right sort of >>>>>>>>>>>> RA's, I guess? A little weird, but flexible. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No, the issue here is that we still want Stateful DHCPv6. I just >>>>>>>>>>> don't want dnsmasq issuing the RA. I want Addressing from >>>>>>>>>>> OpenStack, but not routing (I.e. No RA) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 >> >> <PastedGraphic-1.png> >> _______________________________________________ >> 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
