Re: Granularity (was Re: [RRG] ALT + NERD is inelegant & inefficient, compared to APT or Ivip)

[Brian Dickson <briand@ca.afilias.info>]

Brian E Carpenter wrote:
>   
> > The idea is to make *less* work by splitting the problem space in two.
> >     
>
> How does that apply in the case of a site that changes from single
> homed to dual homed to triple homed and back again? I expect this
> will be a very common occurrence.
>   
If the instance of triple homed is really a question of switching which 
second provider is being used,
then I think a suitable question to dig further along this is:

How important is it that while migrating, a site be able to use *all 
three* links, if only the redundancy is critical?

And, how likely is it that the uninvolved link will fail during the 
transition window for the other two links, as well as
one of the other two links failing simultaneously? Would that be any 
worse than if both links failed, before or
after the transition event? Is having the third link available to do a 
fast transition (or fast reversion) adequate
to meet the needs of a site which isn't so concerned with redundancy as 
to operate their own EID infrastructure?

If we can generalize this to being, "It is common operational practice 
to have an overlap period between
the provisioning of one service, and the cancellation of another 
service, and a 'hot' cut-over between those
during the overlap duration", then I think it's okay to not support 
temporary triple-homing.

Making the distinction between full-on triple-homing, and having three 
links, two of which must always be
configured for redundancy, is IMHO a reasonable situation.

When there is one link that doesn't change, and two that are in the 
hot-cut mode (one add, one drop),
the stability and redundancy is quite reasonable with a solution limited 
to N=2. IMHO.

BTW - reminder about the N=2 distinction. I should point out, that the 
"heavyweight" solution without
host granularity, is also available even in N=2. The compromise is, no 
host granularity, and more administrative,
technical, financial, and operational overhead is required.

Brian Dickson

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg