On 12/03/2009, at 2:27 PM, Rob Austein wrote:
At Thu, 12 Mar 2009 11:49:53 +1000, Terry Manderson wrote:
I don't remember seeing the a make-before-break issue raised in any
draft, can you point me to a reference?
May not have gotten into any draft, but keeping routing live has
certainly been an assumed requirement for some of us. :)
Not saying it isn't - just observing that I don't recall reading that
clearly fundamental requirement :)
Think about corporate acquisitions for a moment. EngulfAndDevour,
headquartered in region A, buys MomAndPopISP, in region B.
MomAndPopISP is a going concern whose founders want to retire, grow
tomatoes, and deal with no unit of time shorter than a season.
EngulfAndDevour has paid heavily for good will of MomAndPopISP's
customer base and wants MomAndPopISP's routing to continue to work
during transfer of MomAndPopISP's resources from region B to region A.
Any downtime at all is unacceptable. Hence make-before-break.
As a corporate acquisition, wouldn't EngulfAndDevour using its
acquired relationships ask for some strong co-ordination between
region A's RIR and region B's RIR? Perhaps requesting that their
certificate shift and re-issuance (and ROA move) happen in a near
simultaneous fashion at UTC 0100hrs? I would have hoped to count on
such organisations to be well coordinated.
But wasn't this structure for ERX? Not for general corporate take-overs?
Further - and this is probably just me, but if the co-ordination
function cannot be counted on - I don't think I would be moving
resources from one region to another, when network downtime is
unacceptable. (maybe that is too sensible ;)
As stated, I would much prefer that the structure be as simple as
possible, and the co-ordination function be improved through some
inter-RIR brokerage/exhange/transfer protocol. I wonder (just thinking
aloud) if there would be dire consequences of a 24hr overlap in
information. Clearly a question about RP decision time if the ROAs
differ.. but other than that? (maybe a @beers discussion)
Terry
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
