Le 18/11/2011 22:58, Ted Lemon a écrit :
On Nov 18, 2011, at 7:14 PM, "Alexandru
Petrescu"<alexandru.petre...@gmail.com> wrote:
But don't scare people away with the word "deployment". Initial
deployments are often just lab settings, a desk, a pocket
sometimes.
Sure, but the question is whether you have a real situation where you
are forced to use DHCP and not RA, or just a hypothetical situation.
RA defroutes don't work for me because there may be not enough
memory space next to the DHCP daemon on a 400MHz ARM processor of
mobile router.
Huh, I have a 400MHz ARM system that runs a full Linux kernel
including DHCPv4 client and RA (which is in the kernel). It's a
Sheeva CPU, so it's a little slow, but I haven't had any problems at
all with this: where I've had problems is compiling kernels in
reasonable amounts of time. So I really, really have trouble
believing that this device can't do RA.
Sure, a 400MHz device could have large enough memory to hold both DHCP
and ND implementations. However, if one tries to reduce the software to
a bare minimum then one would eliminate as many components as possible -
and RA vs DHCP is obvious duplicate functionality, double code line
counts. This would give place for other necessary components like a
route exchange software.
When memory is limited there is compromise to be made, and software
components to be traded off.
No, it is not this reason for me. In my particular case I am
fully aware of RAs offering defroute, and aware of DHCPv4 and
DHCPv6 Relays. In my lab setting it is easier to maintain de conf
files centrally on a unique machine rather than on 5-like Access
Routers. I do not have a std mechanism to remotely update the RA
information these Access Routers offer. But for DHCP I have this
central conf file.
Okay, so why do you want this? I don't mean to say you shouldn't
want it, but can you explain why you want it?
I emulate a wifi operator network: several Access Routers and a single
point maintaining the dhcp conf files. Some AR may offer the Default
Route of another router on the same link (hence the need to have conf
files).
Alex
I do not work for a vendor. I don't see why calling the DHCP
defroute a "vendor" option. On another hand I could agree with it
being EXPERIMENTAL at this point in time.
As Lorenzo said in the meeting, if you give it an option code, it
will see wide implementation, regardless of whether it's standard,
informational or experimental, because lots of people say they want
it. So from an architectural standpoint, we can't punt on the
question of whether we need it.
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
