mesh portal discovery
dcbw at redhat.com
Wed Jan 9 17:20:35 EST 2008
On Wed, 2008-01-09 at 17:18 -0500, Michail Bletsas wrote:
> > In the School Server case, using DHCP as the allowed us to collapse two
> > steps of the connection process into one. With the previous method, you
> > would have to _both_ find the MPP using the non-standard MPP discovery
> > method, and second do a DHCP run to get your address from the school
> > server. Using DHCP here _already_ can provide the address of your
> > gateway.
> We still had to modify DHCP in order to send the request to the anycast
> address in order to be able to find the optimum path to it.
> If we are not doing that anymore, then we can only hope that the "closest"
> server replies first...
To be fair here, the patch was trivial and a lot less work than writing,
auditing, and testing the behavior of a custom solution.
> > You could conceivably do both these operations in parallel but since you
> > have to do DHCP anyway, it's pointless to do some other MPP discovery
> > mechanism. In a school setting autoip might work, but might mean more
> > traffic because of potential address conflicts and the resolution
> > process. So if you want dynamic addressing in the school, DHCP is about
> > the only easy way to do that, and once you're using DHCP the old MPP
> > discovery mechanism is pointless.
> You are doing these operations concurrently all the time since you always
> have to do path discoveries.
> I can't see how autoIP will generate more traffic than DHCP with short
> > The above benefit does not apply in the XO-as-MPP case because autoip
> > addressing is used, however the same codepath is used in NetworkManager
> > as the school server case, and therefore there is less code to maintain,
> > and fewer codepaths to test, and fewer opportunities for stuff to go
> > wrong.
> Yes and the penalty that we pay is very long connection times and disabled
> by default XO MPP functionality :-(
More information about the Devel