On Oct 7, 2011, at 6:08 PM, Erik Nordmark wrote: > On 10/7/11 2:18 PM, Ole Troan wrote: >>>> I think it's >>>> reasonable to write to stable storage whenever you configure a new >>>> prefix or change an existing prefix (but not if you simply refresh it). >>>> If the router comes back up and nobody has the prefix, it would simply >>>> claim it back. If someone else has it, it would have to just form a new >>>> one using loop detection. >>> >>> In your view, if there is a single prefix assigned to the home by the ISP, >>> and there are three routers connected to a particular link in the home, >>> would each of those three routers assign a different prefix to the link? >>> >>> Am I missing something? >> >> see the zospf draft. the DR of the link will assign the prefix for the link. >> the BDR should also store that chosen prefix into stable storage. of course >> if you power off both the DR and the BDR and power up a new 3rd router, the >> link will get a new prefix. > > The zospf draft (see section 3.6) declares a conflict if two routers attached > to the same link pick the same IP subnet prefix for that link. That doesn't > seem what we want. > > 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.
> > 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.) > > 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? No manual intervention is definitely a goal. > > Who is working on the requirements document? ;-) For now, the arch document will be capturing as close as we are getting to formal requirements in an ID.... mostly principles and high-level requirements. I'm not convinced a detailed or separate requirements document for any of our 5 areas could be produced without it becoming a reverse engineering exercise from various solutions anyway. We tried to have a formal "just the requirements" discussion during the meeting, and what I heard was quite a bit of solution discussion couched in requirements language anyway. - Mark > > Erik > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
