Re: Size of CR in CRH

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

Joel,

“Re:  So, you are criticizing Ron”

No, I am questioning adoption poll of an “undercooked” document with a “major” architecture change and technical issues.

Yes, I am also questioning lack of an architecture document that was supposed to answer all these questions raised during adoption poll.

Yes, I am questioning motivation for removing SRm6 normative reference (as Spring is the only documented use-case)?
See https://mailarchive.ietf.org/arch/msg/spring/oevPSxoZ5qxutFDUuJh9Uw22930/

Yes, I am interested to participate in the discussion point raised by Nick.

Thanks

Regards … Zafar

From: "Joel M. Halpern" <[e-mail]>
Date: Thursday, May 21, 2020 at 5:03 PM
To: "Zafar Ali (zali)" <[e-mail]>
Cc: 6man <[e-mail]>
Subject: Re: Size of CR in CRH

So you are criticizing Ron for being very responsive to the questions
that were raised during the document discussion?  That seems rather
backwards.

And then objecting to private discussions when we all know that is often
the most useful way to sort things out.  (I have multiple discussions
with Darren to help determine what text he could put in to address my
concerns with the SRH document.  Those were very helpful.)

Yours,
Joel

On 5/21/2020 4:38 PM, Zafar Ali (zali) wrote:
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]<mailto:[e-mail]>> on behalf of Ron Bonica
<rbonica=[e-mail]<mailto:rbonica=[e-mail]>>
*Date: *Thursday, May 21, 2020 at 10:35 AM
*To: *Nick Hilliard <[e-mail]<mailto:[e-mail]>>
*Cc: *6man <[e-mail]<mailto:[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]> <mailto:[e-mail]><mailto:[e-mail]%3e>>

Sent: Thursday, May 21, 2020 6:24 AM

To: Ron Bonica <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]%3e>>

Cc: 6man <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]%3e>>

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]> <mailto:[e-mail]>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

--------------------------------------------------------------------


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