mesh portal discovery

[Dan Williams]

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 
> leases.
> 
> > 
> > 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 :-(
> 
> M.
>