Re: Size of CR in CRH

[Nick Hilliard <[e-mail]>]

Ron Bonica wrote on 21/05/2020 03:51:
> Does having two CRH versions really add operational complexity, given
> that operators will be advised to run one or another?
> 
> Why not let the operator choose which version is best for its
> network? They probably know better than us.

yeah, it really does add complexity.

I don't see a straightforward way of hiding the implementation details 
in a configuration grammar, at least not portably across vendors.  This 
means implementing complexity right down the tool chain and creating 
operational / support awareness about the fact there would be N 
different varieties of CRH, semantically similar but not the same.

If you merge networks with different SID sizes, this will be disruptive 
because there's no clear migration mechanism between one size and 
another, so changing SID size would mean a flag day. Probably retooling too.

It's not just operational complexity, btw - using multiple SID sizes has 
a long trail of consequences at a protocol level too.  For example, how 
would you signal this in bgp?  Separate afis?  Same AFI but different 
tlvs for each different type? Then how do you handle arbitrage?  Tom 
made some suggestions, but these also have consequences.

If the prevailing WG opinion is to make multiple SID size options 
available, then we need to describe in detail how this is going to work 
right across the board, and how to minimise the downstream impact.  If 
we don't then this pushes the consequence heap into other peoples' laps 
and they may not appreciate this.

Nick