Le 05/02/2014 15:01, Ole Troan a écrit :
Ted,
please take a look at those drafts, and let us know what we've
missed in the DHCP PD "solution space".
I've read all those drafts at one time or another. I just
checked the latest version of
http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf and
it appears to do pretty much the right thing.
One thing that isn't mentioned in that draft that I don't think is
intuitive to all readers is that if you have two CERs, this
technique still works; the only difference is that the technique
has to be done independently by each internal router with respect
to each CER.
you make it sound like that's a part and parcel of DHCP. I can't see
how you can implement that today. are there any implementations doing
this? I have never seen any. as an example of the problems you'll
encounter. how does the RR detect the difference between a backup DR
and a separate DR? first case it should pick the best server, second
case it should set up sessions to both.
Ole,
I think the RR would not need to detect a full difference, but maybe to
obtain prefixes from both, and subsequently distinguish between them
maybe based on some preference values.
If I am not wrong the same scheme of preferences based on lifetime as ND
uses, is also used in PD (valid lifetime and preferred lifetime).
I guess the RR could also indicate some preference value when requesting
prefixes.
It would then come down to a more intelligent decision making at the RR.
Obtaining two prefixes from two different servers is not that huge of a
problem, I think.
This draft also does not appear to talk about how to get rid of
prefixes to CERs that have failed. Ideally the homenet routing
protocol server could signal the DHCPv6 PD requesting router
server when a CER has gone away, or else the PD requesting router
server could poll for that information from time to time (you want
a little hysteresis to avoid needlessly dropping prefixes in the
event of a router reboot, of course).
"homenet routing protocol server"? this proposal makes do with
static routing.
given an arbitrary topology. how do you build the relay topology and
discover DHCP servers?
I think it is good to question how would Relays discover servers.
But that does not mean that OSPF-or-other-routing-protocol doesn't need
same thing.
Where one questions the use of multicast - OSPF also relies on it.
use site-local multicast -> we don’t quite know how to bootstrap
that?
OSPF also relies on same multicast paradigm. If we know how to do it
for OSPF then we'd know for DHCP as well.
hop-by-hop relaying?
?
how do you deal with loops?
Loops in a small setting like a homenet may be primarily a matter of
where does the default route point to. In the immediate, one wants to
make sure these default routes don't lead to loops. This is a reason
why one may question how is the default route delivered.
A routing protocol which maintains routes will indeed detect loops, but
will do little in itself to inform a Host that what it believes to be a
default route should not be used. A routing protocol needs to rather
inform a Router to modify its radvd.conf towards that Host. That isn't
implemented either in widespread implementations, as far as I know.
Or, one wouldn't want a routing protocol to replace RA for the default
route, right?
you're essentially building a spanning tree of relays. how do you
deal with multiple routers on the link? just keep adding /64s out of
the same site-prefix to it?
how does the network react to network events? given you rely on DHCP
snooping then network convergence time is rather glacial.
while DHCP PD may look like a candidate at first glance, to make it
work in all corner cases, you essentially build something quite
different than current DHCP. then you might as well use a real
routing protocol and a prefix assignment protocol designed for the
purpose.
Hm.
Alex
cheers, Ole
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
