Subject: What 's the process?

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 18 Feb 2020 10:41:52 +0000

Hi Ron,

I see the related references to segment routing documents are deleted, including https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-00

May I ask a question? What is the relation between this document and the SRm6 document? Independent?  If not, what is the process of adopting these two documents? 

BTW, in which condition that we can say a solution is a stand-alone piece of work?

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, February 17, 2020 8:56 AM
To: 6man WG <[email-masked]>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

Over the last several weeks, customers who have no interest in Segment Routing have expressed interest in the CRH. So, we have updated the CRH draft, removing all references to Segment Routing and letting it stand alone as an IPv6 Routing header.

While Segment Routing may one day be a user of the CRH, it will not be the only user.

Please review this document as a stand-alone piece of work.

                                                                          Ron

Juniper Business Use Only

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]>; Ning So <[email-masked]>; Andrew Alston <[email-masked]>; Ning So <[email-masked]>; Tomonobu Niwa <[email-masked]>; Andrew Alston <[email-masked]>; Yuji Kamite <[email-masked]>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

A new version of I-D, draft-bonica-6man-comp-rtg-hdr-11.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:		draft-bonica-6man-comp-rtg-hdr
Revision:	11
Title:		The IPv6 Compressed Routing Header (CRH)
Document date:	2020-02-16
Group:		Individual Submission
Pages:		16
URL                      https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11
Status:                https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/
Htmlized:           https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11
Htmlized:           https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr
Diff:           
Abstract:
   This document defines two new Routing header types.  Collectively,
   they are called the Compressed Routing Headers (CRH).  Individually,
   they are called CRH-16 and CRH-32.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Tue, 18 Feb 2020 23:07:23 +0000

Hello Cheng, Robin and Darren,

The CRH draft depends only upon the documents that it references as normative. It does not depend on any other documents.
Do you see anything in the text that suggests otherwise?

The use-case is exactly the same as RH0. The application needs a traffic steering mechanism. However, there are two new constraints. These are:

	- The security vulnerabilities that caused RH0 to be deprecated must be addressed
	- The Routing header must be deployable, even when the number of segments is large

In the future, other document may depend on CRH. However, CRH does not depend upon them.

                                                                                                 Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, February 18, 2020 5:42 AM
To: Ron Bonica <rbonica=[email-masked]>; 6man WG <[email-masked]>
Subject: What 's the process?

Hi Ron,

I see the related references to segment routing documents are deleted, including https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-00__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrD0I-8D$ 

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, February 17, 2020 8:56 AM
To: 6man WG <[email-masked]>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

                                                                          Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]>; Ning So <[email-masked]>; Andrew Alston <[email-masked]>; Ning So <[email-masked]>; Tomonobu Niwa <[email-masked]>; Andrew Alston <[email-masked]>; Yuji Kamite <[email-masked]>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Name:		draft-bonica-6man-comp-rtg-hdr
Revision:	11
Title:		The IPv6 Compressed Routing Header (CRH)
Document date:	2020-02-16
Group:		Individual Submission
Pages:		16
URL                      https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrnJ8ZXY$ 
Status:                https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjuJwFxBl$ 
Htmlized:           https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrnJ8ZXY$ 
Htmlized:           https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjsOwC5Gy$ 
Diff:           
Abstract:
   This document defines two new Routing header types.  Collectively,
   they are called the Compressed Routing Headers (CRH).  Individually,
   they are called CRH-16 and CRH-32.

The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrjvNnZo$ 
--------------------------------------------------------------------

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 19 Feb 2020 18:09:39 +0000

Thanks Ron, so CRH is now purely an RH0 replacement in your view, and the use-case is exactly the same as RH0.
However:
 - your RH0 replacement has only one documented use-case and that is SRm6.
 - your RH0 replacement defines traffic engineering semantics in the CRH-FIB, that are unrelated to RH0 and only useful to SRm6.

It is pretty obvious to me (and I think anyone else watching) that you are attempting to jump the queue here Ron.
You are attempting to get 6man to stamp CRH for use by SRm6 without doing the work that you agreed to; documenting the benefits of SRm6 vs existing SR/MPLS and SRv6 solutions https://mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs.

I commend you on the attempt, but I think it is a bit too obvious to work ;)

Darren

On Feb 18, 2020, at 6:07 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

                                                                                                Ron

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, February 18, 2020 5:42 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: What 's the process?

Hi Ron,

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, February 17, 2020 8:56 AM
To: 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

                                                                         Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Tomonobu Niwa <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Yuji Kamite <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

---

From: Ron Bonica <[email-masked]>
Date: Wed, 19 Feb 2020 18:59:36 +0000

Darren,

Do you deny the possibility that an operator who has no interest in SR might want to steer IPv6 traffic?

                                                                                                                        Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]>
Sent: Wednesday, February 19, 2020 1:10 PM
To: Ron Bonica <[email-masked]>
Cc: Chengli (Cheng Li) <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; 6man WG <[email-masked]>; Lizhenbin <[email-masked]>
Subject: Re: What 's the process?

It is pretty obvious to me (and I think anyone else watching) that you are attempting to jump the queue here Ron.
You are attempting to get 6man to stamp CRH for use by SRm6 without doing the work that you agreed to; documenting the benefits of SRm6 vs existing SR/MPLS and SRv6 solutions https://mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs__;!!NEt6yMaO-gk!QzvfV9GH7ysN3nxfgajnS3g94y1A7aAJ1ZugRKtrxlCaKM7YYOV_o7eBfXa9ulu8$>.

Darren

                                                                                                Ron

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, February 18, 2020 5:42 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: What 's the process?

Hi Ron,

I see the related references to segment routing documents are deleted, including https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-00__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrD0I-8D$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-00__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrD0I-8D$>

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, February 17, 2020 8:56 AM
To: 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

                                                                         Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Tomonobu Niwa <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Yuji Kamite <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Name: draft-bonica-6man-comp-rtg-hdr
Revision: 11
Title: The IPv6 Compressed Routing Header (CRH)
Document date: 2020-02-16
Group: Individual Submission
Pages: 16
URL                      https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrnJ8ZXY$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrnJ8ZXY$>
Status:                https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjuJwFxBl$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjuJwFxBl$>
Htmlized:           https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrnJ8ZXY$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrnJ8ZXY$>
Htmlized:           https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjsOwC5Gy$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjsOwC5Gy$>
Diff:
Abstract:
  This document defines two new Routing header types.  Collectively,
  they are called the Compressed Routing Headers (CRH).  Individually,
  they are called CRH-16 and CRH-32.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!QzvfV9GH7ysN3nxfgajnS3g94y1A7aAJ1ZugRKtrxlCaKM7YYOV_o7eBfSml9HQL$>.

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

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

---

From: Ron Bonica <[email-masked]>
Date: Wed, 19 Feb 2020 20:48:01 +0000

Darren,

Replying more gently, I have customers who want to steer IPv6 traffic without deploying SR. Their segment lists can be quite long.

Some are traditional service providers. Some are cloud providers.

                                                                                         Ron

Juniper Business Use Only
From: Ron Bonica
Sent: Wednesday, February 19, 2020 2:00 PM
To: Darren Dukes (ddukes) <[email-masked]>
Cc: Chengli (Cheng Li) <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; 6man WG <[email-masked]>; Lizhenbin <[email-masked]>
Subject: RE: What 's the process?

Darren,

                                                                                                                        Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 19, 2020 1:10 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>
Subject: Re: What 's the process?

Darren

                                                                                                Ron

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, February 18, 2020 5:42 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: What 's the process?

Hi Ron,

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, February 17, 2020 8:56 AM
To: 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

                                                                         Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Tomonobu Niwa <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Yuji Kamite <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

The IETF Secretariat

---

From: James Guichard <[email-masked]>
Date: Wed, 19 Feb 2020 20:54:29 +0000

Hi Ron,

Having reminded myself of what RH0 was 😉 CRH seems very different given it is not a standalone IPv6 extension header since it introduces a notion of SIDs as its base forwarding construct. These SIDs need to be advertised and signaled via routing protocols and other mechanisms (indicating that other documents will in fact be necessary and therefore become a dependency) in order to distribute the mapping tables and setup the CRH FIB. This is quite different from RH0 which used IPv6 addresses as segments and did not need any new extensions in IPv6 routing protocols (CLI does not count in a serious deployment).

Respectfully,

Jim

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: Tuesday, February 18, 2020 6:07 PM
To: Chengli (Cheng Li) <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; 6man WG <[email-masked]>; Lizhenbin <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>
Subject: RE: What 's the process?

                                                                                                 Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, February 18, 2020 5:42 AM
To: Ron Bonica <rbonica=[email-masked]>; 6man WG <[email-masked]>
Subject: What 's the process?

Hi Ron,

I see the related references to segment routing documents are deleted, including https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-spring-sr-mapped-six-00__%3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrD0I-8D%24&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf325d28ab1194a15d80b08d7b4c75ee8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637176640701783834&amp;sdata=1wWvn7hS%2BCScwWpHv9g1OtbkiLnxYIwdqZwxytD%2B8t8%3D&amp;reserved=0 

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, February 17, 2020 8:56 AM
To: 6man WG <[email-masked]>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

                                                                          Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]>; Ning So <[email-masked]>; Andrew Alston <[email-masked]>; Ning So <[email-masked]>; Tomonobu Niwa <[email-masked]>; Andrew Alston <[email-masked]>; Yuji Kamite <[email-masked]>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Name:		draft-bonica-6man-comp-rtg-hdr
Revision:	11
Title:		The IPv6 Compressed Routing Header (CRH)
Document date:	2020-02-16
Group:		Individual Submission
Pages:		16
URL                      https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr-11__%3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrnJ8ZXY%24&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf325d28ab1194a15d80b08d7b4c75ee8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637176640701783834&amp;sdata=67qEaIRngkDzSDe%2FkJjgQbV2DTS0BoHZxAhspP53j%2B0%3D&amp;reserved=0 
Status:                https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-bonica-6man-comp-rtg-hdr%2F__%3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjuJwFxBl%24&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf325d28ab1194a15d80b08d7b4c75ee8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637176640701783834&amp;sdata=SSVeM4lVk63SiHraCxcK05tuZjJwcRrnlhUCq2eHUXM%3D&amp;reserved=0 
Htmlized:           https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr-11__%3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrnJ8ZXY%24&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf325d28ab1194a15d80b08d7b4c75ee8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637176640701783834&amp;sdata=67qEaIRngkDzSDe%2FkJjgQbV2DTS0BoHZxAhspP53j%2B0%3D&amp;reserved=0 
Htmlized:           https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr__%3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjsOwC5Gy%24&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf325d28ab1194a15d80b08d7b4c75ee8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637176640701783834&amp;sdata=ZPpncF4XNkzxuIvf42MeXyxbgavHyhAZIigp4PhKoOs%3D&amp;reserved=0 
Diff:           
Abstract:
   This document defines two new Routing header types.  Collectively,
   they are called the Compressed Routing Headers (CRH).  Individually,
   they are called CRH-16 and CRH-32.

The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6__%3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrjvNnZo%24&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf325d28ab1194a15d80b08d7b4c75ee8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637176640701783834&amp;sdata=7Z5j1Y5UdGZX0Ctj3DolRX4AQhAJGJ918cIZUj%2FnXTI%3D&amp;reserved=0 
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6__%3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrjvNnZo%24&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf325d28ab1194a15d80b08d7b4c75ee8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637176640701783834&amp;sdata=7Z5j1Y5UdGZX0Ctj3DolRX4AQhAJGJ918cIZUj%2FnXTI%3D&amp;reserved=0 
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf325d28ab1194a15d80b08d7b4c75ee8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637176640701783834&amp;sdata=NKKItAzgkIUrUVX3yOl7VBUpAD%2BsTeTgPczsvWIFdv4%3D&amp;reserved=0
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Wed, 19 Feb 2020 21:44:32 +0000

Jim,

CRH is clearly not the same as RH0! Compression is a new requirement.

AFAICS, there are two ways to compress a routing header. These are:

- By making the SID represent an entry in a table like the CRH-FIB.
- By making the SID the only parameter to an algorithm that yields an IPv6 address.

I chose the former approach because the later only works when network addressing conforms to its requirements.

As I say in the draft, the CRH-FIB can be populated:

- through the CLI
- through a controller
- through distributed routing protocols

The protocols that support these interfaces are beyond the scope of the current draft.

                                                                                                                         Ron

-----Original Message-----
From: James Guichard <[email-masked]> 
Sent: Wednesday, February 19, 2020 3:54 PM
To: Ron Bonica <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; 6man WG <[email-masked]>; Lizhenbin <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>
Cc: James Guichard <[email-masked]>
Subject: RE: What 's the process?

Hi Ron,

Respectfully,

Jim

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: Tuesday, February 18, 2020 6:07 PM
To: Chengli (Cheng Li) <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; 6man WG <[email-masked]>; Lizhenbin <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>
Subject: RE: What 's the process?

                                                                                                 Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, February 18, 2020 5:42 AM
To: Ron Bonica <rbonica=[email-masked]>; 6man WG <[email-masked]>
Subject: What 's the process?

Hi Ron,

I see the related references to segment routing documents are deleted, including https://urldefense.com/v3/__https://nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-bonica-spring-sr-mapped-six-00__*3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrD0I-8D*24&amp;data=02*7C01*7Cjames.n.guichard*40futurewei.com*7Cf325d28ab1194a15d80b08d7b4c75ee8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637176640701783834&amp;sdata=1wWvn7hS*2BCScwWpHv9g1OtbkiLnxYIwdqZwxytD*2B8t8*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!Vb81uRPH66S9jp_Z6E-EZGHvEgJY87e5D92z1L8wDm1EHI9AThX_OgI2C8wxxOyP$  

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, February 17, 2020 8:56 AM
To: 6man WG <[email-masked]>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

                                                                          Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]>; Ning So <[email-masked]>; Andrew Alston <[email-masked]>; Ning So <[email-masked]>; Tomonobu Niwa <[email-masked]>; Andrew Alston <[email-masked]>; Yuji Kamite <[email-masked]>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Name:		draft-bonica-6man-comp-rtg-hdr
Revision:	11
Title:		The IPv6 Compressed Routing Header (CRH)
Document date:	2020-02-16
Group:		Individual Submission
Pages:		16
URL                      https://urldefense.com/v3/__https://nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-bonica-6man-comp-rtg-hdr-11__*3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrnJ8ZXY*24&amp;data=02*7C01*7Cjames.n.guichard*40futurewei.com*7Cf325d28ab1194a15d80b08d7b4c75ee8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637176640701783834&amp;sdata=67qEaIRngkDzSDe*2FkJjgQbV2DTS0BoHZxAhspP53j*2B0*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!Vb81uRPH66S9jp_Z6E-EZGHvEgJY87e5D92z1L8wDm1EHI9AThX_OgI2C1SWvMbn$  
Status:                https://urldefense.com/v3/__https://nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-bonica-6man-comp-rtg-hdr*2F__*3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjuJwFxBl*24&amp;data=02*7C01*7Cjames.n.guichard*40futurewei.com*7Cf325d28ab1194a15d80b08d7b4c75ee8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637176640701783834&amp;sdata=SSVeM4lVk63SiHraCxcK05tuZjJwcRrnlhUCq2eHUXM*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Vb81uRPH66S9jp_Z6E-EZGHvEgJY87e5D92z1L8wDm1EHI9AThX_OgI2C4_zAwos$  
Htmlized:           https://urldefense.com/v3/__https://nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-bonica-6man-comp-rtg-hdr-11__*3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrnJ8ZXY*24&amp;data=02*7C01*7Cjames.n.guichard*40futurewei.com*7Cf325d28ab1194a15d80b08d7b4c75ee8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637176640701783834&amp;sdata=67qEaIRngkDzSDe*2FkJjgQbV2DTS0BoHZxAhspP53j*2B0*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!Vb81uRPH66S9jp_Z6E-EZGHvEgJY87e5D92z1L8wDm1EHI9AThX_OgI2C1SWvMbn$  
Htmlized:           https://urldefense.com/v3/__https://nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-bonica-6man-comp-rtg-hdr__*3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjsOwC5Gy*24&amp;data=02*7C01*7Cjames.n.guichard*40futurewei.com*7Cf325d28ab1194a15d80b08d7b4c75ee8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637176640701783834&amp;sdata=ZPpncF4XNkzxuIvf42MeXyxbgavHyhAZIigp4PhKoOs*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Vb81uRPH66S9jp_Z6E-EZGHvEgJY87e5D92z1L8wDm1EHI9AThX_OgI2C_wEfuPT$  
Diff:           
Abstract:
   This document defines two new Routing header types.  Collectively,
   they are called the Compressed Routing Headers (CRH).  Individually,
   they are called CRH-16 and CRH-32.

The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fipv6__*3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrjvNnZo*24&amp;data=02*7C01*7Cjames.n.guichard*40futurewei.com*7Cf325d28ab1194a15d80b08d7b4c75ee8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637176640701783834&amp;sdata=7Z5j1Y5UdGZX0Ctj3DolRX4AQhAJGJ918cIZUj*2FnXTI*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!Vb81uRPH66S9jp_Z6E-EZGHvEgJY87e5D92z1L8wDm1EHI9AThX_OgI2Cyjq8yFG$  
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fipv6__*3B!!NEt6yMaO-gk!SZBw1bJrNzc15rJ32cZACDoLU6rdesCKqqb7L_Kk7fAG01S3NeZHhGXcjrjvNnZo*24&amp;data=02*7C01*7Cjames.n.guichard*40futurewei.com*7Cf325d28ab1194a15d80b08d7b4c75ee8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637176640701783834&amp;sdata=7Z5j1Y5UdGZX0Ctj3DolRX4AQhAJGJ918cIZUj*2FnXTI*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!Vb81uRPH66S9jp_Z6E-EZGHvEgJY87e5D92z1L8wDm1EHI9AThX_OgI2Cyjq8yFG$  
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fipv6&amp;data=02*7C01*7Cjames.n.guichard*40futurewei.com*7Cf325d28ab1194a15d80b08d7b4c75ee8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637176640701783834&amp;sdata=NKKItAzgkIUrUVX3yOl7VBUpAD*2BsTeTgPczsvWIFdv4*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Vb81uRPH66S9jp_Z6E-EZGHvEgJY87e5D92z1L8wDm1EHI9AThX_OgI2C2TMFAFb$ 
--------------------------------------------------------------------

---

From: Andrew Alston <[email-masked]>
Date: Thu, 20 Feb 2020 02:18:34 +0000

Darren,

I've given a lot of thought to what I'm going to say next - and the fact that a lot of it is repetition of what I have said over, and over, and over again - much of which you have chosen to never respond to.  In that vein - I am going to take this in point form, and I encourage you to go back through the emails I have sent over the last year or more for expansion on each of these points, in a similar way to how people need to read RFC's before questioning their content.

Let us start with - what is the use case -

  1.  We need to be able to steer traffic
     *   In a way that is compatible with inter-domain traffic steering (this works with CRH, we've proved it: https://mailarchive.ietf.org/arch/msg/spring/KeWOkXeN9JPv8acD1oC99qjdsxU
     *   We need ways to steer traffic that allow us to do this with very deep stack depth - going as deep as 10 or 12 SID's - without the vast traffic overhead that would exist in the case of SRv6 - while at the same time maintaining the ability to track the packet through the header (which is accomplished through the immutable nature of the header)
     *   We need to be able to cross segments of the network that have no support for SR-MPLS in the context of IPv6 - and this is particularly important considering statements from certain vendors that they have no plans or desires to implement SR-MPLS as concerns IPv6 - despite supporting it for IPv4.

Now, with that said -

  1.  We do not need, want, or require
     *   Overly complex programmability - some may - that is simply not something we see a need for today - I don't begrudge those that do need it or wish to implement it
     *   Anything that results in what I have heard as described as routing by NAT in order to reduce the header size.
     *   To violate rfc8200 through either the insertion or deletion of headers in flight
     *   To inflate the size of the IGP by separating our loopbacks and our SID's
     *   To run into problems as concerns RFC7112 when the SID depth becomes deep enough
     *   To utilize any protocol that fundamentally redefines the semantics of an IPv6 address with all the unintended consequences this may entail

Next - let me address another point.  You constantly question the use case.  Let me state this, what is a use case.  It is that which an operator, or group of operators utilize a technology for, that they find beneficial and that enhances their network.  It is that simple.  In the context of the requirements above, we strongly feel that other proposals out there do not meet our needs, in any way shape or form.  We do however know for a fact that what is defined in the CRH draft - does - it works - its deployed - it exists - and it meets a need.  Now, just as I said we have no requirement of all the items in B, you may not see a requirement in your context for what we need out of CRH - that does not make our use case any less valid, it simply makes it irrelevant to what you believe is required by yourself, in the same way that what you have defined has no relevance of our network today.  That is not a bad thing - but - different things work for different networks in different environments.

Speaking for myself, I have no desire to see SRv6, the network programming draft or the rest stopped or work to cease on them.  I acknowledge that some people may have a requirement for things in those documents, however, those documents do not come CLOSE to addressing that which is required on our network, and instead, violate several key principles by which we operate, including the introduction of technologies which in our view are overly complex, excessively difficult to debug, risk redefinition of already existent standards without knowledge of the unintended consequences, and so the list continues.  CRH in and of itself is a new routing header - it meets a requirement that we have, and if we saw that requirement as a result of the studying of other documents and upon the realization that those documents did not meet that requirement at all, is irrelevant.

What I have not seen over the last while however, is you disputing the technical feasibility of the document.  Your arguments are pretty consistent regarding what you believe is about use case - except, when myself, and others, have clearly stated that we have a use case for something else, and indeed with the amount of time spent developing both the documents and the code, this argument is clearly contra-indicated through both these statements and that work.  Interestingly enough, it is also contra-indicated through the introduction of the micro-sid draft, because the moment you published that - which came after the initial publication of the CRH document, you acknowledged the need for header compression, and you acknowledged through the very existence of that document that there is a fundamental requirement to reduce the header size imposed.  If you dispute that, then I cannot understand why said draft exists.

Now, if you wish me to go and write yet another rfc draft to define why we need this - and in the absence of any such documents describing the use cases for various other documents, I will do so, however, I do not wish to waste the time of people to deal with yet another draft when the on these lists, and at the microphone, time and again, these things have already been clearly articulated, and ignored.

So let me be clear - SRv6 does not have a place on our network - it does not meet our requirements - it will never meet our requirements - it has no use case within our domain - CRH on the other hand - does meet our requirements, it has a use case, and it works.  And while for another operator, the inverse may be true, and for some, they may see benefit in running BOTH technologies, that does not negate either of the technologies.

Thanks

Andrew

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 20 Feb 2020 19:18:13 +0000

Ron, you’ve said customers do not want to ‘deploy SR’, but CRH does not propose anything that is different than SR.  Let me explain.

Section 1 of RFC8402 talks about SR and what it is. At its most basic ‘deploy SR’ involves:
- Assign prefix and/or adjacency SIDs with domain-wide or local significance (respectively)
- Build SR Policies using said SIDs and steer traffic through those policies.

Now let’s look at the CRH.
- You define a prefix SID and an adjacency SID (section 4) with domain-wide or local significance (respectively)
   - the equivalent is defined in SR architecture (RFC8402).
- The only way to use the SIDs is to steer traffic through a policy that would apply the SID list as a CRH header, though you do not yet say this in the draft.
   - the equivalent is defined in SR architecture as an SR policy.

I do not think you’ll be shocked at this revelation Ron; you have created an alternate source routing header for Segment Routing. :-0

You’ve not pointed to any use of CRH other than SRm6 even though you removed references.

Darren

On Feb 19, 2020, at 3:48 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Darren,

                                                                                         Ron

To: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>

Darren,

                                                                                                                        Ron

Darren

                                                                                                Ron

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, February 18, 2020 5:42 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: What 's the process?

Hi Ron,

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, February 17, 2020 8:56 AM
To: 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

                                                                         Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Tomonobu Niwa <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Yuji Kamite <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

The IETF Secretariat

---

From: Ron Bonica <[email-masked]>
Date: Thu, 20 Feb 2020 19:23:17 +0000

Darren,

Please take a look at emails posted by Andrew Alston and John Scudder earlier today. I think that they have refuted the points that you are raising.

                                                                                       Ron

Sent: Thursday, February 20, 2020 2:18 PM

Ron, you've said customers do not want to 'deploy SR', but CRH does not propose anything that is different than SR.  Let me explain.

Section 1 of RFC8402 talks about SR and what it is. At its most basic 'deploy SR' involves:
- Assign prefix and/or adjacency SIDs with domain-wide or local significance (respectively)
- Build SR Policies using said SIDs and steer traffic through those policies.

Now let's look at the CRH.

I do not think you'll be shocked at this revelation Ron; you have created an alternate source routing header for Segment Routing. :-0

You've not pointed to any use of CRH other than SRm6 even though you removed references.

Darren

Darren,

                                                                                         Ron

Darren,

                                                                                                                        Ron

Darren

                                                                                                Ron

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, February 18, 2020 5:42 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: What 's the process?

Hi Ron,

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, February 17, 2020 8:56 AM
To: 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

                                                                         Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Tomonobu Niwa <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Yuji Kamite <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

The IETF Secretariat

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 20 Feb 2020 12:01:34 -0800

Amen to Andrew's email as to technical terms ... As "procedural objections"
side-swipe: IETF is (still?) rough consensus, running code & ideally
deployment rather than ceremony and process lawyering ... And yes, ideally
not breaking standards published v6 drafts and hi-jacking address semantics
because they're "just bits" ...

I guess in shorter terms +1 for adoption here

--- tony

On Wed, Feb 19, 2020 at 6:20 PM Andrew Alston <
[email-masked]> wrote:

> Darren,
>
>
>
> I’ve given a lot of thought to what I’m going to say next – and the fact
> that a lot of it is repetition of what I have said over, and over, and over
> again – much of which you have chosen to never respond to.  In that vein –
> I am going to take this in point form, and I encourage you to go back
> through the emails I have sent over the last year or more for expansion on
> each of these points, in a similar way to how people need to read RFC’s
> before questioning their content.
>
>
>
> Let us start with – what is the use case –
>
>
>
>       1. In a way that is compatible with inter-domain traffic steering
>       (this works with CRH, we’ve proved it:
>       https://mailarchive.ietf.org/arch/msg/spring/KeWOkXeN9JPv8acD1oC99qjdsxU
>       2. We need ways to steer traffic that allow us to do this with very
>       deep stack depth – going as deep as 10 or 12 SID’s – without the vast
>       traffic overhead that would exist in the case of SRv6 – while at the same
>       time maintaining the ability to track the packet through the header (which
>       is accomplished through the immutable nature of the header)
>       3. We need to be able to cross segments of the network that have no
>       support for SR-MPLS in the context of IPv6 – and this is particularly
>       important considering statements from certain vendors that they have no
>       plans or desires to implement SR-MPLS as concerns IPv6 – despite supporting
>       it for IPv4.
>
>
>
> Now, with that said –
>
>
>
>       1. Overly complex programmability – some may – that is simply not
>       something we see a need for today – I don’t begrudge those that do need it
>       or wish to implement it
>       2. Anything that results in what I have heard as described as
>       routing by NAT in order to reduce the header size.
>       3. To violate rfc8200 through either the insertion or deletion of
>       headers in flight
>       4. To inflate the size of the IGP by separating our loopbacks and
>       our SID’s
>       5. To run into problems as concerns RFC7112 when the SID depth
>       becomes deep enough
>       6. To utilize any protocol that fundamentally redefines the
>       semantics of an IPv6 address with all the unintended consequences this may
>       entail
>
>
>
> Next – let me address another point.  You constantly question the use
> case.  Let me state this, what is a use case.  It is that which an
> operator, or group of operators utilize a technology for, that they find
> beneficial and that enhances their network.  It is that simple.  In the
> context of the requirements above, we strongly feel that other proposals
> out there do not meet our needs, in any way shape or form.  We do however
> know for a fact that what is defined in the CRH draft – does – it works –
> its deployed – it exists – and it meets a need.  Now, just as I said we
> have no requirement of all the items in B, you may not see a requirement in
> your context for what we need out of CRH – that does not make our use case
> any less valid, it simply makes it irrelevant to what you believe is
> required by yourself, in the same way that what you have defined has no
> relevance of our network today.  That is not a bad thing – but – different
> things work for different networks in different environments.
>
>
>
> Speaking for myself, I have no desire to see SRv6, the network programming
> draft or the rest stopped or work to cease on them.  I acknowledge that
> some people may have a requirement for things in those documents, however,
> those documents do not come CLOSE to addressing that which is required on
> our network, and instead, violate several key principles by which we
> operate, including the introduction of technologies which in our view are
> overly complex, excessively difficult to debug, risk redefinition of
> already existent standards without knowledge of the unintended
> consequences, and so the list continues.  CRH in and of itself is a new
> routing header – it meets a requirement that we have, and if we saw that
> requirement as a result of the studying of other documents and upon the
> realization that those documents did not meet that requirement at all, is
> irrelevant.
>
>
>
> What I have not seen over the last while however, is you disputing the
> technical feasibility of the document.  Your arguments are pretty
> consistent regarding what you believe is about use case – except, when
> myself, and others, have clearly stated that we have a use case for
> something else, and indeed with the amount of time spent developing both
> the documents and the code, this argument is clearly contra-indicated
> through both these statements and that work.  Interestingly enough, it is
> also contra-indicated through the introduction of the micro-sid draft,
> because the moment you published that – which came after the initial
> publication of the CRH document, you acknowledged the need for header
> compression, and you acknowledged through the very existence of that
> document that there is a fundamental requirement to reduce the header size
> imposed.  If you dispute that, then I cannot understand why said draft
> exists.
>
>
>
> Now, if you wish me to go and write yet another rfc draft to define why we
> need this – and in the absence of any such documents describing the use
> cases for various other documents, I will do so, however, I do not wish to
> waste the time of people to deal with yet another draft when the on these
> lists, and at the microphone, time and again, these things have already
> been clearly articulated, and ignored.
>
>
>
> So let me be clear – SRv6 does not have a place on our network – it does
> not meet our requirements – it will never meet our requirements – it has no
> use case within our domain – CRH on the other hand – does meet our
> requirements, it has a use case, and it works.  And while for another
> operator, the inverse may be true, and for some, they may see benefit in
> running BOTH technologies, that does not negate either of the
> technologies.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>