Erik,
And zospf doesn't talk about using stable storage; doesn't seem to have any
notion of providing stable prefixes assigned to the links.
Thus this problem remains to be solved AFAICT.
The draft is useful background, but I think some work remains. Maybe even a lot
of work. So yes.
I think we first need to agree on what we think are the requirements on prefix
stability. What if one of the routers attached to the link fails and is
replaced by a different router?
What if a link partitions? And later merges?
What the user intentionally splits (partitions) a link (e.g., to create a
separate link for the teenage game room); should the network automatically pick
a new prefix for that new link? (How does that interact with the prefix being
in stable storage on the router.)
We talked about the stability requirements on Thursday a bit. From my
perspective the requirement is that crashes, power outages/recycles, and
addition of new devices must not cause existing allocations to change. Other
changes.... they may, and I think it would be too much effort and complexity to
try to prevent all changes in all situations.
One thing to keep in mind as we think about these requirements is that if the
user has created a bridged Ethernet with no routers, all of the above will work
naturally; might take seconds to relearn when the topology changes but there is
no manual intervention needed.
Is that the goal for this prefix assignment?
Who is working on the requirements document? ;-)
Ole was working on the slides for the requirements, but many of the entries
probably need some further details. (Like Mark, I think it would be probably
more worthwhile to move a bit back and forth between solutions and requirements
rather than make a pure requirements list.)
Jari
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
