RE: What 's the process?

[Ron Bonica <[e-mail]>]

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



Juniper Business Use Only
From: Darren Dukes (ddukes) <[e-mail]>
Sent: Thursday, February 20, 2020 2:18 PM
To: Ron Bonica <[e-mail]>
Cc: Chengli (Cheng Li) <[e-mail]>; Ron Bonica <rbonica=[e-mail]>; 6man WG <[e-mail]>; Lizhenbin <[e-mail]>
Subject: Re: What 's the process?

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

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) <[e-mail]<mailto:[e-mail]>>
Cc: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>; Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>; 6man WG <[e-mail]<mailto:[e-mail]>>; Lizhenbin <[e-mail]<mailto:[e-mail]>>
Subject: RE: What 's the process?

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) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, February 19, 2020 1:10 PM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
Cc: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>; Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>; 6man WG <[e-mail]<mailto:[e-mail]>>; Lizhenbin <[e-mail]<mailto:[e-mail]>>
Subject: Re: What 's the process?

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<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs__;!!NEt6yMaO-gk!QzvfV9GH7ysN3nxfgajnS3g94y1A7aAJ1ZugRKtrxlCaKM7YYOV_o7eBfXa9ulu8$>.

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

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


Juniper Business Use Only

-----Original Message-----
From: ipv6 <[e-mail]<mailto:[e-mail]>> On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, February 18, 2020 5:42 AM
To: Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>; 6man WG <[e-mail]<mailto:[e-mail]>>
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$>

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:[e-mail]] On Behalf Of Ron Bonica
Sent: Monday, February 17, 2020 8:56 AM
To: 6man WG <[e-mail]<mailto:[e-mail]>>
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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>; Ning So <[e-mail]<mailto:[e-mail]>>; Andrew Alston <[e-mail]<mailto:[e-mail]>>; Ning So <[e-mail]<mailto:[e-mail]>>; Tomonobu Niwa <[e-mail]<mailto:[e-mail]>>; Andrew Alston <[e-mail]<mailto:[e-mail]>>; Yuji Kamite <[e-mail]<mailto:[e-mail]>>
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://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
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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$>
--------------------------------------------------------------------