RE: Size of CR in CRH

[Ron Bonica <[e-mail]>]

Tom,

That's one way to mitigate the complexity. For example, the 32-bit value 0x0000beef and the 16-bit value 0xbeef both identify the same CRH-SID entry.

Another way is with configuration syntax. A single configuration knob might enable:


  *   The sending of either CRH-16 or CRH-32
  *   The processing (upon receipt) of both

That way, a network merge or a transition from CRH-16 to CRH-32 wouldn't be so painful.

                                                                   Ron




Juniper Business Use Only
From: Tom Herbert <[e-mail]>
Sent: Thursday, May 21, 2020 10:42 AM
To: Ron Bonica <[e-mail]>
Cc: Nick Hilliard <[e-mail]>; 6man <[e-mail]>
Subject: Re: Size of CR in CRH

[External Email. Be cautious of content]

Ron,

I believe if these are considered compressed values that are just used in the on-the-wire datapath then that would mitigate would complexity in the control plane. For instance, uncompressed identifiers can be used in tables, configuration, for conveying in BGP independently of whether compression is being used in datapath.

Tom

On Thu, May 21, 2020, 7:34 AM Ron Bonica <rbonica=[e-mail]<mailto:[e-mail]>> wrote:
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<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Vmpd73kOda_CZ63XD-PC8dCL-8pyFt9yozF6aJ3YP8RrC8OOw2QPKGmPP9sqjIEM$>
--------------------------------------------------------------------