Subject: RE: Size of CR in CRH

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 21 May 2020 02:12:12 +0000

Hi Bob, Ron, and Robert,

Personally agree with 32-bit.

I don't think we will develop any data plane just for today not for the future. Also, the key problem is how long should we wait for the 5G era? Definitely, the answer is different between people. In China, it means 0 days or <1 year.

So it will be good to limit the option to help the discussion. 

Also, 16 bits do not mean 65536 IDs, it is only in the paper like Robert said.
In IP address planning, we use the bits to indicate location, for example, 4 bits to indicate cores, 6 bits to indicate the Aggregate nodes, and 6 bits to indicate Access nodes.
In the best case, we may have 65K nodes, but actually we can not get there.  Because of the nodes in each level/each block are vary because of the development of the geography area.

Unless, you use the 16 bits without structure, yes, we can reach 65 K, but it may be hard for operation, and personally don't think this is a good idea.

I suppose that the answer is in anyone's mind, but I can not guess that. 

Best regards,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Thursday, May 21, 2020 7:03 AM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Size of CR in CRH

Ron,

> On May 20, 2020, at 2:54 PM, Ron Bonica <[email-masked]> wrote:
> 
> Fred,
> 
> We know that:
> 
> - Today, nearly all service provider networks contain fewer than 65K routers. A 16-bit identifier will be good enough for them.
> - Today, many Data Centers include more than 65k routers. This number includes software-based routers that reside on servers. They require a 32-bit identifier.
> - Today, many service providers have multiple stand-alone operations 
> groups. They may want to allocate a block of identifiers to each 
> group, resulting in sparely populated identifier space. They may 
> require a 32-bit identifier
> - In the future, 5G networks may contain as many as 1,000,000 Cell Site Routers. They may require a 32-bit identifier.

Based on this sounds like a 32-bit identifier would meet current and future requirements.    Suggest just doing that.

I note this would allow using this hybrid service provider data center networks.

Bob

> 
>                                                                                                                    
> Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Fred Baker <[email-masked]>
> Sent: Wednesday, May 20, 2020 5:32 PM
> To: Mark Smith <[email-masked]>; Ron Bonica 
> <[email-masked]>
> Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
> Subject: Re: Size of CR in CRH
> 
> Speaking strictly for myself...
> 
> This is a question:
> 
> What is the probability of needing 65536 code points, 131072 code points, etc, etc?
> 
> Could the problem of N*0x0ffff code points be addressed by allocating N code points, each of which has 0xFFFF minor code points? Issues include operational overhead and a variety of other things. Note that the usual argument for large prefixes and large numeric groups tend to mention operational overhead.
> 
> Discuss...
> 
>> On May 20, 2020, at 2:24 PM, Mark Smith <[email-masked]> wrote:
>> 
>> Hi Ron,
>> 
>> On Thu, 21 May 2020 at 04:41, Ron Bonica 
>> <rbonica=[email-masked]> wrote:
>>> 
>>> Bob,
>>> 
>>> First, let's agree that the problem with having two CRH versions:
>>> 
>>> - is complexity
>>> - is not code point consumption
>>> 
>> 
>> There's an operational issue with having two or more sizes, which is 
>> the risk and possible future consequences of choosing the small size 
>> when you might need the or a larger size in the future.
>> 
>> To change any significant production network from one size to another 
>> is going to involve a lot of planning, may involve disrupting 
>> customers' services, and is likely to involve a lot of out of hours 
>> work. (I like to think of out of hours work as 10 times harder than 
>> in-hours work, so my view is to try to avoid incurring out of hours 
>> work unless there is no other choice.)
>> 
>> In this case of 16 bit verses 32 bits, it sounds like the main cost 
>> of choosing 32 bits will be in ASICs that support them.
>> 
>> So for an operator, it sounds like a choice between writing a bigger 
>> cheque today to buy bigger ASICs, or the possibility of still having 
>> to buy bigger ASICs later (granted, likely cheaper due to natural 
>> scales of economy) and then getting less sleep, disrupting customers 
>> etc. to put the new ASIC equipment in.
>> 
>> I think operators are used to writing pretty big upfront cheques for 
>> equipment, because they're used to buying extra equipment and links 
>> for redundancy, just in case of failures.
>> 
>> Note that I'm not arguing specifically for 32 bits here, just that if 
>> there is a choice between a variety of sizes, the largest choice is 
>> normally the least risky operational choice.
>> 
>> A single single size would be better operationally, as long as that 
>> single size is large enough to cover most use cases. Other special 
>> cases that can't be accommodated sound like they need their own 
>> special and different solution.
>> 
>> Regards,
>> Mark.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> Given that agreement, we look for ways to reduce complexity. Options are:
>>> 
>>> - find ways to reduce complexity while retaining two CRH versions
>>> - drop one CRH version
>>> 
>>> The following are ways to reduce complexity while retaining two CRH versions:
>>> 
>>> - Recommend that operators run one CRH version or the other, but not 
>>> both, except during transition periods
>>> - Facilitate transition by making the 16-bit identifier, with value N, reference the same CRH-FIB entry as the 32-bit identifier that also has value N.
>>> 
>>> And, of course, we could drop the CRH-32, at least for the time being. But I don't think that this is the right decision because we have heard three arguments for CRH 32, with these being:
>>> 
>>> - the O-RAN argument (presented by me)
>>> - the Data Center Underlay argument (presented by Uma)
>>> - the sparsely populated identifier argument (presented by Andrew).
>>> 
>>> While the O-RAN argument may be speculative, the other two are not.
>>> 
>>> 
>>> Ron
>>> 
>>> 
>>> Juniper Business Use Only
>>> 
>>> -----Original Message-----
>>> From: Bob Hinden <[email-masked]>
>>> Sent: Wednesday, May 20, 2020 12:46 PM
>>> To: Ron Bonica <[email-masked]>
>>> Cc: Bob Hinden <[email-masked]>; Nick Hilliard 
>>> <[email-masked]>; 6man <[email-masked]>
>>> Subject: Re: Size of CR in CRH
>>> 
>>> Ron,
>>> 
>>> Thanks, this is helpful.  Comments inline.
>>> 
>>> Bob
>>> 
>>> 
>>>> On May 20, 2020, at 9:03 AM, Ron Bonica <[email-masked]> wrote:
>>>> 
>>>> Hi Bob,
>>>> 
>>>> AFAICS, a 16-bit identifier is good enough for any network that exists today. And until very recently, I believed that a 16-bit identifier was good enough for any network that might exist for many years to come.
>>> 
>>> Good
>>> 
>>>> 
>>>> However, 5G may change all of that. The promise of 5G is high data rates from the user-device to the cell tower. In order to achieve these high data rates, the user-device and cell tower communicate with one another over extremely high radio frequencies. These extremely high radio frequencies do not propagate well over long distances. So, there will be *many* cell towers.
>>>> 
>>> 
>>> I understand that part of 5G.
>>> 
>>>> The O-RAN Alliance is exploring transport architectures in which each cell tower hosts a Cell Site Router (CSR) and each CSR can be the endpoint of a traffic engineered path. In that architecture, a 32-bit CR may be required, because there may be as many as 1,000,000 CSRs.
>>>> 
>>>> Yes, this is a bit speculative. But it may happen.
>>> 
>>> CRH could start with a 16-bit identifier.   Once the O-RAN work is further along, a new routing header with 32-bit identifiers could be developed if needed.   As you said, there isn’t a shortage of routing header types and would make the specification and implementations simpler.
>>> 
>>>> 
>>>> This is the motivation for having two sizes. We don't want to deprive existing networks of optimal compression because of future speculation. But we don't want to close the door on 5G support, either.
>>>> 
>>>> 
>>>> Ron
>>>> 
>>>> P.S. ASICs can generally handle 16, 24 and 32 bit CRs. However, some are more efficient when word-alignment is maintained. This makes 16 and 32 more desirable.
>>>> 
>>>> 
>>>> 
>>>> Juniper Business Use Only
>>>> 
>>>> -----Original Message-----
>>>> From: Bob Hinden <[email-masked]>
>>>> Sent: Tuesday, May 19, 2020 11:05 PM
>>>> To: Ron Bonica <[email-masked]>
>>>> Cc: Bob Hinden <[email-masked]>; Nick Hilliard 
>>>> <[email-masked]>; 6man <[email-masked]>
>>>> Subject: Re: Size of CR in CRH
>>>> 
>>>> Ron,
>>>> 
>>>> A few comments inline.
>>>> 
>>>>> On May 19, 2020, at 11:01 AM, Ron Bonica <[email-masked]> wrote:
>>>>> 
>>>>> Hi Nick, Bob and Fred
>>>>> 
>>>>> The following factors figured into the decision to specify 2 Routing types, one with a 16-bit identifier and the other with a 32-bit identifier:
>>>>> 
>>>>>    - Today, very few networks contain more than 65,000 routers. So, most networks could obtain best compression with a 16-bit identifier.
>>>> 
>>>> Are there any networks today where 16 bits is too small?
>>>> 
>>>>>    - When 5G is deployed, we may see networks that contain more than 65,000 Cell Site Routers. These networks will need an identifier that is wider than 16 bits.
>>>> 
>>>> This seems pretty speculative to me.  Do you have any justification for this?   Is there a 5G document that discusses this?
>>>> 
>>>> This is also assuming that each router needs to be identified uniquely and that every router on a path needs to be in the source route.  How long will each path be.   Source routing won’t scale well with large numbers of hops regardless of the size identifier.
>>>> 
>>>> 
>>>>>    - It is unlikely that we will ever see a network that contains more than 4,000,000 routers. So, we will never need an identifier that is wider than 32 bits.
>>>>> 
>>>>> If Routing header types were in short supply, and only one were available to us, we would have to do one of the following:
>>>>> 
>>>>>    - Select a single length (16, 24 or 32 bits)
>>>>>    - Use the fifth byte of the Routing header to indicate the identifier length.
>>>>> 
>>>>> The first option isn't very appealing. A 16-bit identifier is too short for some networks.
>>>> 
>>>> s/too short for some networks/too short for some future networks/  ??   Are there any today, even close?
>>>> 
>>>>> A 24-bit identifier may be difficult for some ASICs to process. A 32-bit identifier gives suboptimal compression for all existing networks.
>>>> 
>>>> So I assume that ASICs can’t process a 32-bit identifier either?
>>>> 
>>>>> 
>>>>> The second option isn't very appealing either. If we use the fifth byte to indicate the identifier length, and we want the first identifier to begin on a 32-bit boundary, the next 24 bits would be wasted.
>>>>> 
>>>>> Fortunately, Routing header types are not in short supply. The Routing Type registry has room for 255 entries. Since it was established 25 years ago, only 6 types have been allocated. Of those, two have been deprecated (RH0 and Nimrod) and two are for special use (Experiment 1 and Experiment 2).
>>>> 
>>>> I don’t think the availability of router header types is a good justification for two headers.
>>>> 
>>>> Having two headers now adds complexity given what I think I am hearing that there isn’t a need for a bigger identifier for long time in the future.
>>>> 
>>>> Bob
>>>> 
>>>>> 
>>>>> So, allocating two Routing types may be the best solution.
>>>>> 
>>>>> 
>>>>> Ron
>>>>> 
>>>>> 
>>>>> 
>>>>> Juniper Business Use Only
>>>>> 
>>>>> -----Original Message-----
>>>>> From: ipv6 <[email-masked]> On Behalf Of Nick Hilliard
>>>>> Sent: Tuesday, May 19, 2020 1:13 PM
>>>>> To: Bob Hinden <[email-masked]>
>>>>> Cc: 6man <[email-masked]>
>>>>> Subject: Re: Size of CR in CRH
>>>>> 
>>>>> [External Email. Be cautious of content]
>>>>> 
>>>>> 
>>>>> Bob Hinden wrote on 19/05/2020 00:08:
>>>>>> I also prefer a single size (and only one SR header definition).   If
>>>>>> it’s 16-bits, that would allow 64K routers in one CRH domain 
>>>>>> assuming it needs to uniquely identify each router, if there is 
>>>>>> more than 64K routers, then it only needs to identify the routers 
>>>>>> that are serving as hops in the source route.
>>>>>> 
>>>>>> As you note 24 bits is better, but may not align as well.   Or then
>>>>>> 32-bits.
>>>>> 
>>>>> Having multiple options for SID size increases complexity at 
>>>>> several
>>>>> levels: hardware programming, CLI, network compatibility, troubleshooting, etc.  What happens if a network wants to change from using one type of SID to another because of whatever reason?  Does a node need to be configured with multiple IDs?  Can you mix and match?
>>>>> These sorts of things matter when you run networks.  You're increasing the complexity of some aspects by a factor of two.
>>>>> 
>>>>> Simplicity is a huge gain from an operational point of view.
>>>>> 
>>>>> 32 bits has the advantage of being the same size as a node's bgp or ospf router-id.  This would be something ranging from helpful to important if the device has an option for manual programming.
>>>>> 
>>>>> The EH packet header lookup size of a device obviously impacts this.
>>>>> 
>>>>> Nick
>>>>> 
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> - IETF IPv6 working group mailing list [email-masked] 
>>>>> Administrative
>>>>> Requests:
>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
>>>>> i
>>>>> pv
>>>>> 6
>>>>> __;!!NEt6yMaO-gk!UCWrvkvflbEehBiEIA8M4PHGA_mrvC0MLpZly-euihAg3_3aS
>>>>> j
>>>>> RJ
>>>>> L
>>>>> LRAZuRumqRr$
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> -
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list [email-masked] Administrative 
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 02:51:43 +0000

Bob, Cheng,

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.

                                                  Ron

-----Original Message-----
From: Chengli (Cheng Li) <[email-masked]> 
Sent: Wednesday, May 20, 2020 10:12 PM
To: Bob Hinden <[email-masked]>; Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: Size of CR in CRH 

Hi Bob, Ron, and Robert,

Best regards,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Thursday, May 21, 2020 7:03 AM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Size of CR in CRH

Ron,

Bob

>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ip
>>> v6__;!!NEt6yMaO-gk!XPnOjFQ1_gSGKZ7XmrDkei_WWaoyZ3t5FChIi0A-IvGPkkwKc
>>> vgDUvOT9cT_Uee2$
>> Administrative Requests: 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv
>> 6__;!!NEt6yMaO-gk!XPnOjFQ1_gSGKZ7XmrDkei_WWaoyZ3t5FChIi0A-IvGPkkwKcvg
>> DUvOT9cT_Uee2$

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 May 2020 11:24:18 +0100

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

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 14:34:07 +0000

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

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

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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 May 2020 07:41:46 -0700

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=
[email-masked]> 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
>
>
>
> 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.
>
> 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.
>
> 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

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 14:51:44 +0000

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 <[email-masked]>
Sent: Thursday, May 21, 2020 10:42 AM
To: Ron Bonica <[email-masked]>
Cc: Nick Hilliard <[email-masked]>; 6man <[email-masked]>
Subject: Re: Size of CR in CRH

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=[email-masked]<mailto:[email-masked]>> wrote:
Nick,

                                                                 Ron

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

Nick
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
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$>
--------------------------------------------------------------------

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 21 May 2020 20:38:55 +0000

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 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Thursday, May 21, 2020 at 10:35 AM
To: Nick Hilliard <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: Size of CR in CRH

Nick,

                                                                 Ron

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

Why not let the operator choose which version is best for its network?
They probably know better than us.

Nick

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 20:53:34 +0000

Zafar,

I would be  glad to.

                    Ron

Juniper Business Use Only
From: Zafar Ali (zali) <zali=[email-masked]>
Sent: Thursday, May 21, 2020 4:39 PM
To: Ron Bonica <[email-masked]>; Nick Hilliard <[email-masked]>
Cc: 6man <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: Size of CR in CRH

Hi Ron,

Thanks

Regards … Zafar

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

Nick,

                                                                 Ron

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

Nick
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Tz5HN2OUyzzuUmQWYUp0Tv5oVECYm0yuaRAdkUvigiRyLS1rJAxvgrFO91AXcdJr$>
--------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 21 May 2020 17:02:55 -0400

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:
> *From: *ipv6 <[email-masked]> on behalf of Ron Bonica 
> <rbonica=[email-masked]>
> *Date: *Thursday, May 21, 2020 at 10:35 AM
> *To: *Nick Hilliard <[email-masked]>
> *Cc: *6man <[email-masked]>
> *Subject: *RE: Size of CR in CRH
> 
> Nick,
> 
> From: Nick Hilliard <[email-masked] <mailto:[email-masked]>>
> 
> To: Ron Bonica <[email-masked] <mailto:[email-masked]>>
> 
> Cc: 6man <[email-masked] <mailto:[email-masked]>>
> 
> [email-masked] <mailto:[email-masked]>
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 21 May 2020 21:51:08 +0000

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" <[email-masked]>
Date: Thursday, May 21, 2020 at 5:03 PM
To: "Zafar Ali (zali)" <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Size of CR in CRH

Yours,
Joel

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 <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica
<rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
*Date: *Thursday, May 21, 2020 at 10:35 AM
*To: *Nick Hilliard <[email-masked]<mailto:[email-masked]>>
*Cc: *6man <[email-masked]<mailto:[email-masked]>>
*Subject: *RE: Size of CR in CRH

Nick,

                                                                   Ron

-----Original Message-----

From: Nick Hilliard <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>

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

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

Nick

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Bob Hinden <[email-masked]>
Date: Thu, 21 May 2020 15:15:29 -0700

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=[email-masked]> wrote:
> 
> Joel,
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 21 May 2020 22:15:14 -0700

Thanks Bob.