Assuming we work out the BRSKI questions such that bootstrapping during disaster recovery is clearly defined I’d imagine the rest of anima work work “magically” — in that the new equipment added to a network does what it is intended to do automatically.
- max > On Nov 13, 2016, at 12:02 AM, Michael Richardson <mcr+i...@sandelman.ca> > wrote: > > > Toerless Eckert <t...@cs.fau.de> wrote: >>> Devices that have been brought up and are in the network post >>> bootstrap are not relevant to the BRSKI document. > >> To me the most important goal should be to provide candidate users with >> deployment guidance. This should fit ANIMA goals given how its an OPS >> group. > > Chairs, > I think we should add a new document to our set. The title might be: > Autonomic Networking in Disaster Recovery: preperation and operation > > This would be a very very very operational BCP. > We won't finish this until after everything has been put to bed, but I think > we should start it soonest, so that we can capture much of this > discussion/concern. > >> a) keep spares unenrolled, enrol during desaster recovery with >> satellite link b) enrol spare devices when they are stocked, deploy >> during desaster. > >> lets assume we agree both are relevant deployment options that users >> should understand, compare pro/cons for their case and choose. If you >> think we can not mention both in the BRSKY spec, then i think it would >> be better to have a separate document where both could be discussed. > > A reason why one would have unenrolled spares is because the spares are kept > by the manufacturer in distributed warehouses, close to where they might be > needed, or perhaps even, would be in a FEMA-like entities' warehouse, to be > deployed to whichever operator needed them. > > The use of Autonomic mechanisms might result in normalization much of the > configuration of some devices, so it wouldn't matter as much which vendor's > device was deployed. Maybe this won't be for core BGP-happy BFRs, but it > could be the case that less complicated things like 24 10/100/1000s switches > would be in that category. > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
