On 17/11/2016 12:42, Max Pritikin (pritikin) wrote: > > 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.
Yes, that would be the plan ;-). It might be worth understanding how cellphone systems deal with this. After a disaster (as this week in Kaikoura NZ) there's initially no electricity and no link out from the base stations. How do they rebuild the trust infrastructure so that SIM cards from anywhere in the world can connect? Does this only work after there's a connection to the provider's infrastructure? http://www.stuff.co.nz/business/industries/86463492/options-being-assessed-for-restoring-phone-services-to-kaikoura Brian > > - 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 > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
