mesh portal discovery

[Michail Bletsas]

> 
> 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...

> 
> 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.