Re: Size of CR in CRH

[Erik Kline <[e-mail]>]

Thanks Bob.

On Thu, May 21, 2020 at 3:16 PM Bob Hinden <[e-mail]> wrote:
>
> Zafar,
>
> The 6man chairs, after consulting with our ADs, decided to proceed with this adoption call.
>
> You can say in response to the adoption call, you support or do not support adoption and cite the reasons for that, but questioning the adoption poll itself is not constructive.
>
> Further, questioning someone’s motivation is also not constructive.
>
> Bob
>
> > On May 21, 2020, at 2:51 PM, Zafar Ali (zali) <zali=[e-mail]> wrote:
> >
> > 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]> 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
> >>
> >> --------------------------------------------------------------------
> >>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------