Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

[Alexandre Petrescu <[e-mail]>]

Le 21/11/2018 à 16:37, Ole Troan a écrit :
[...]
>> Do you know of a software implementation that runs on embedded 
>> platform openWRT that does both DHCPv6-PD _and_ RA Default Route 
>> and does not use two software packages?
> 
> Yes. VPP.

Thank you for this pointer.  It stands for Vector something.

>> If you do _not_ know, do you think that it is not a problem that 
>> there are two software packages for PD+defroute?
> 
> Even when I do know, I don’t think it’s a problem. PD is a router to
>  router protocol, RS/RA is a host to router. And you can perfectly 
> well run PD without RS/RA.

This is a very important point.

The way in which you qualify it makes think you have a particular idea
about what is a router, and that gives a clear idea to you.

However, there are circumstances where this assumed definition of a
Router (or of a Host for that matter), may get out of the frame you
may have set.

In these circumstances, it would be appropriate either to discard their
existence (say 'that's not a Router'), or try to update the existing
specs of what routers do.

As one example, this case of DHCPv6-PD and Default Route is a perfect
exponent of circumstance where your assumptions do not apply purely: my
home CPE needs both a Default Route with RA (so, byr current RFCs it's a 
Host, not a Router), and a delegated prefix with DHCPv6-PD (so it's a 
Router, not a Host).

Other examples abound, out of which allow me to go further and cite 
RFC4191 "More Specific Routes" - that spec is only for Hosts, but there 
are routers in cars doing car-to-car communications that need it for 
Routers too.

>>> As they are independent of each other, practically it’s done in a
>>> single RTT.
>> 
>> No, this is a wrong statement.  Currently RS/RA and DHCP are not in
>> a single RTT.
> 
> “Practically single RTT”. You send the SOLICIT and RS back to back.

Yes.

> 
>>> How slow a link are you talking about? A 10kbps link does about 
>>> 14 packets per second. So even on that you would manage to do 
>>> RS/RA and SOLICIT/REPLY in about 1/2th of a second. (Doing a 
>>> little bit of a guess on packet sizes).
>> 
>> There are many degrees in using terms 'slow'.  What Fred mentions 
>> as air links I see as a limit, but there are many degrees up to 
>> that limit where the problem is still valid.
>> 
>> When I write about embedded platforms being limited I mean all 
>> these hardware platforms, _and_ communication links, that range 
>> from Ethernet 10GBps and 8GHz clock 32Gb RAM down to Lora and 32kb
>>  RAM.
>> 
>> In most of these intermediary platforms there is a problem of 
>> putting _two_ software packages like SLAAC and DHCP 
>> implementations.
>> 
>> Most of these, if not all, need defroute _and_ prefix delegation.
> 
> Nothing forcing you to implement this as separate packages. As if 
> that matters very much. VPP has it as a single package. The real 
> small stuff tend to use protocols developed in 6lo et al.

I will have to look at VPP in more detail.

Let me just add that small platforms and links is a larger domain
than what 6lo does.  And that 6lo is probably not answering many of the
other IP needs in these small platforms and links.

For example: if one wants the end-to-end principle of IP (node pings
google) then one wants IP in the small computer.  That would disqualify 
6lo's compression, or exact-match MAC forwarding, or lack of subnet 
structure, etc.

These small computers would however need IP default routes, delegated
prefixes, and acceptable forwarding speed (not necessarily ultra-high 
performance fast forwarding).

>>> Executive summary: Your claims are not reality checked.
>> 
>> I gave earlier a precise example of openwrt.
> 
> There is other running code where this does not apply. Your argument
>  of using a particular implementation choice to set direction for 
> standarisation is dubious.

No.  With all due respect, it seems dubious to make standards based on 
what big Switches and Routers want.

Unless, of course, we state that the end-to-end principle happens only 
between big computers, and seggregate the small computers out.

> 
>> It is _way_ too much software to run both odhcpd _and_ radvd, while
>> also pretending that radvd is deprecated.
>> 
>> It is not only too much in terms of RAM needed by these software 
>> packages, but too much also in terms of skills needed by the 
>> sysadmin or the student, documentation, config files, and more.
>> 
>> I do not understand how one does not see this as being a problem.
> 
> Neither do we understand you seeing it as a problem. ;-)

We do not understand what in draft-naveen should we add to explain to you.

What small suggestion you have to us to add in the draft?

Alex

> 
> cheers, Ole
>