Re: Size of CR in CRH

["Zafar Ali (zali)" <[e-mail]>]

Hi Ron,

Please include the WG in the discussion.

I see there is a lot of “on the fly patching” of an “undercooked” document under adoption poll ☹
This is just another indication why having an architecture document is a must for such a big (data plane) change.

Thanks

Regards … Zafar

From: ipv6 <[e-mail]> on behalf of Ron Bonica <rbonica=[e-mail]>
Date: Thursday, May 21, 2020 at 10:35 AM
To: Nick Hilliard <[e-mail]>
Cc: 6man <[e-mail]>
Subject: RE: Size of CR in CRH

Nick,

Fair enough. Let's initiate a dialog to identify and mitigate the operational complexity. This may require many messages, so let's do that off-line and come back to the mailing list with a summary.

                                                                 Ron



Juniper Business Use Only

-----Original Message-----
From: Nick Hilliard <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, May 21, 2020 6:24 AM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
Cc: 6man <[e-mail]<mailto:[e-mail]>>
Subject: Re: Size of CR in CRH

[External Email. Be cautious of content]


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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------