Hi,
> 3.1. Network Models
>
> In this section we list six network models.
I have no complaint about those 6 models, but the reality is that
in an unmanaged homenet, the topology will be effectively random,
and solutions have to work whatever the user happens to do.
(Or alternatively, some sort of topology wizard would have to
tell the user to disconnect or move particular cables, but that
seems unreasonable.)
Therefore, these 6 models are useful but they can only be
illustrative. The requirement is that stuff works for any topology.
I think this needs to be said as an introduction to section 3.1,
and it prepares the way for sections 3.4.7 "Self-Organising" and
3.4.8 "Fewest Topology Assumptions".
> PD13) The delegation method should support "flash" renumbering.
and
> When an ISP needs to restructure and in doing so renumber its
> customer homenets, "flash" renumbering is likely to be imposed. This
> implies a need for the homenet to be able to handle a sudden
> renumbering event which, unlike the process described in [RFC4192],
> would be without a "flag day".
This needs more analysis. As the draft mentions, homenets are out of
scope for 6renum, and in any case the emphasis there is on planned
renumbering, which seems the only conceivable approach for enterprises.
I think we need to analyse in what way flash renumbering is different
from a cold start. More or less by definition, if we cold start a homenet
(as after a power cut), everything except ULAs will be renumbered, even
if they end up with the exact same addresses again. It's therefore
accurate to say that a cold start will cause flash renumbering but is
that sufficient to meet the requirement? If not, requirement PD13 seems
to be very demanding.
Brian
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
