Subject: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

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

Ron,

I sensed that you will propose that … hence I already asked this question in my last email,

Let me repeat. In rev 10 of the CRH document[1], the following SIDs with normative reference to SRm6 were defined but removed in Feb. 2020:
"The following are valid segment types:
   o Adjacency.
   o Node.
   o Binding. "

Your proposed text is consistent on how CRH was positioned since inception till Feb. 2020, i.e., for SPRING use-case.
However, the very premise of the current adoption call is use-case beyond SPRING.
There is a clear need for documenting a genuine use-case & architecture for CRH beyond SPRING, before adoption.

[1] https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10#section-4

Thanks

Regards … Zafar

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

Robert,

It might makes sense for an operator to:

  *   Allocate identifiers that cause packets to traverse a least-cost path as if they had domain-wide significance
  *   Allocate identifiers that cause packets to traverse specific links as strictly node local

This concept also exists in SR-MPLS, where prefix SIDs have domain-wide scope and adjacency SIDs have node-local scope.

I will make this more clear in the next draft version.

                                        Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Thursday, May 21, 2020 4:34 AM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Size of CR in CRH

[External Email. Be cautious of content]

Ron,

> Now recall that identifiers have node local significance.

I was talking about case described in yr draft section 7:

"Applications can:

       o Allocate SIDs so that they have domain-wide significance."

While not a must - it is an option. So I believe my observation stays valid till draft either removes that option or describes scaling properties differences between both domain wide and local significance of the SIDs.

Thx,
R.

On Thu, May 21, 2020 at 4:01 AM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Consider the following network:

  *   Contains 65,000 routers
  *   Each router has 500 directly connected neighbors or fewer
  *   Uses 16-bit CRH

In this network, each node might have 65,499 CRH-FIB entries:

  *   64,999 CRH-FIB entries cause packets to follow the least-cost path to another node in the domain
  *   500 CRH-FIB entries cause packets to traverse a specific link to a specific neighbor.

As a mnemonic device, an operator might assign identifiers as follows:

  *   0-65,000 identify CRH-FIB entries that cause packets to follow the least-cost path to another node in the domain
  *   65,001 – 65,565 identify CRH-FIB entries that that cause packets to traverse a specific link to a specific neighbor.

Now recall that identifiers have node local significance. So, Node A and Node B might both have a CRH-FIB entry that is identified by the value 65,001. However:

  *   The CRH-FIB entry on Node A causes packets to traverse a particular link towards Node X
  *   The CRH-FIB entry on Node B causes packets to traverse a different link towards Node Y.

I think that this example refutes the premise of your argument, so there is not further need to address the conclusion.

                                                                                         Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 20, 2020 6:20 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: Size of CR in CRH

[External Email. Be cautious of content]

HI,

So just to make sure I understand this analogy of 16 bit -- 2^16 = 65536 nodes. I think this is only on paper.

Imagine I have 1000 routers so if I divide the 16 bit space by 1000 I get at most 65 local node behaviours if anyone would like to embed such into the SID.

That means that if my router have more then 65 interfaces I am not able to steer packets by src route out of my router ... I must always depend on the lookup of next SID how to forward the packets.

That also means that if I want to apply any form of NP in segment endpoint I am quite limited to the number of local functions I could use.

To conclude - Let me restate to what I and others already said - flat SID space domain wide in mapping plane is a mistake. Yes this is like MPLS, but this does not make it great again due to that legacy.

Many thx,
R.

---

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

Well, when I read the latest revision, these terms are modified to other words, but still feel similar.

Also, I still see the sentence in Introduction:

“
The CRH allows IPv6 source nodes to specify the path that a packet
   takes to its destination.
“

To Ron,

is it a Source Packet Routing paradigm?

If yes, we should start from SPRING WG?

Things are going so fast and I don’t understand why a reference deletion can made such magic happen?  ☹

Best Regards,
Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Thursday, May 21, 2020 11:35 PM
To: Ron Bonica <rbonica=[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

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:19 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: Size of CR in CRH

Robert,

-          Allocate identifiers that cause packets to traverse a least-cost path as if they had domain-wide significance
-          Allocate identifiers that cause packets to traverse specific links as strictly node local

                                        Ron

Ron,

"Applications can:

Thx,
R.

·  Contains 65,000 routers

·  Each router has 500 directly connected neighbors or fewer

·  Uses 16-bit CRH

·  64,999 CRH-FIB entries cause packets to follow the least-cost path to another node in the domain

·  500 CRH-FIB entries cause packets to traverse a specific link to a specific neighbor.

·  0-65,000 identify CRH-FIB entries that cause packets to follow the least-cost path to another node in the domain

·  65,001 – 65,565 identify CRH-FIB entries that that cause packets to traverse a specific link to a specific neighbor.

·  The CRH-FIB entry on Node A causes packets to traverse a particular link towards Node X

·  The CRH-FIB entry on Node B causes packets to traverse a different link towards Node Y.

                                                                                         Ron

HI,

Many thx,
R.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 16:58:23 +0000

Cheng,

Are you assuming that the SPRING charter precludes 6man from ever defining another Routing header unless it originates in SPRING?

After all, every IPv6 Routing header facilitates source routing.....

                                                                                                Ron

Juniper Business Use Only
From: Chengli (Cheng Li) <[email-masked]>
Sent: Thursday, May 21, 2020 12:24 PM
To: Zafar Ali (zali) <[email-masked]>; Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: RE: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

"
"

To Ron,

Things are going so fast and I don't understand why a reference deletion can made such magic happen?  :(

Best Regards,
Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Thursday, May 21, 2020 11:35 PM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ron,

I sensed that you will propose that ... hence I already asked this question in my last email,

[1] https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10#section-4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10*section-4__;Iw!!NEt6yMaO-gk!QAuA3Dl83zIeqeKCEhswwSXMzW48zN83GY5D6ZiwWA3VkPM6iOFJIwiYIWmNW_1A$>

Thanks

Regards ... Zafar

Robert,

                                        Ron

Ron,

"Applications can:

Thx,
R.

  *   0-65,000 identify CRH-FIB entries that cause packets to follow the least-cost path to another node in the domain
  *   65,001 - 65,565 identify CRH-FIB entries that that cause packets to traverse a specific link to a specific neighbor.

                                                                                         Ron

HI,

Many thx,
R.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 21 May 2020 17:26:18 +0000

Hi Ron,

It is the 6man charter that precludes it from defining a new Source Routing solution.

"It is not chartered to develop major changes or additions to the IPv6 specifications."

The RH work done in 6man (not ipng or ipv6) has been based on requirements from other WGs where those solutions have been defined and which were chartered do to that work. As such, 6man has simply designed those RHs and not their respective Routing/Source Routing solutions.

"6man is the design authority for extensions and modifications to the IPv6 protocol."

So in which WG is this newly proposed IPv6 Source Routing solution going to be architected in?

Regarding SPRING, the argument is that what you are claiming to be a new IPv6 Source Routing solution is in fact based on SPRING architecture. It seems really unfortunate that significant work done by Spring WG group is re-used without proper attribution. I am not surprised if people still thing this is Segment Routing even after you have removed references, omitted text and renamed terms.

Thanks,
Ketan

From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: 21 May 2020 22:28
To: Chengli (Cheng Li) <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: RE: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Cheng,

                                                                                                Ron

Juniper Business Use Only
From: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 21, 2020 12:24 PM
To: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

"

To Ron,

Best Regards,
Cheng

Ron,

   o Binding.. "

Thanks

Regards ... Zafar

Robert,

                                        Ron

Ron,

"Applications can:

Thx,
R.

                                                                                         Ron

HI,

Many thx,
R.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 May 2020 10:48:22 +1200

On 22-May-20 05:26, Ketan Talaulikar (ketant) wrote:
...> It is the 6man charter that precludes it from defining a new Source Routing solution..
> “It is not chartered to develop major changes or additions to the IPv6 specifications.”

If this addition was major, that would be true. But adding a new RH type is well within the scope of maintenance, IMHO. We have already done it quite recently.

In any case, legalistic arguments about WG charters are really not how we should take technical decisions. 

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 May 2020 10:52:26 +1200

On 22-May-20 03:35, Zafar Ali (zali) wrote:
...
> There is a clear need for documenting a genuine use-case & architecture for CRH beyond SPRING, before adoption.

Why? We are only deciding whether to pass editorial control of the draft to the WG. If the WG wants to add text about the use cases and architecture to the draft, we can do so in due course. It isn't a pre-condition for adoption.

   Brian

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 22 May 2020 03:12:58 +0000

Hi Brian,

Please see my previous response to your comments. 

My argument is not legalistic. I am not as experience in IETF work as you and Bob are. But what I understand is that the reason why we have these "legal" process of charters and BoF is to enable a proper technical discussion with the right context and details of the proposal presented for review of the community. 

I do not see how shortcutting them helps anyone and I wonder why it is being done in this case?

Thanks,
Ketan

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: 22 May 2020 04:18
To: Ketan Talaulikar (ketant) <[email-masked]>; Ron Bonica <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: Re: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Regards
    Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 21 May 2020 20:33:27 -0700

Ketan,

> On May 21, 2020, at 8:12 PM, Ketan Talaulikar (ketant) <ketant=[email-masked]> wrote:
> 
> Hi Brian,
> 

There is no short cutting here.  The adoption call is to determine if there is interest in the w.g. to take this work into 6man.   If it becomes a w.g. draft, then the w.g. is responsible to decide what happens next.

It’s a first step, it is not a decision to publish it.

Bob (w/ w.g. chair hat on)

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 22 May 2020 03:53:05 +0000

Hi Bob,

Perhaps I will try to make my case to you (and everyone else here) … one last time.

This is how I've seen RH work being done in 6man until now (in a matter that fits its charter).

1) There is a WG (not 6man) that defines the problem statement, use-cases and architecture that requires RH

2) The 6man being the experts on IPv6 design, either take up the document that specifies that RH (or even if it is done in another WG, reviews it).

So 6man has always had work done in (1) to reference and lean upon when doing (2).

My argument of the shortcut in the case of this specific adoption is that we don't have (1).

It is not in 6man charter nor expertise to take up (1) because CRH is not purely IPv6 work. It is not meant for "Internet" but a specific "limited domain". The SIDs that it introduces is a new "mapping ID" concept. It is not an IPv6 address and neither it is MPLS. This is a Routing Header and part of a new Source Routing solution.

Therefore, without (1) being made available to 6man, I believe that working on (2) in 6man is to me a shortcutting of the IETF technical review process (specifically of the Routing area in this case) for a solution and does not provide the necessary reference for 6man to work on.

Why the rush?

I close my arguments.

Thanks,

Ketan

-----Original Message-----
From: Bob Hinden <[email-masked]>
Sent: 22 May 2020 09:03
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Brian Carpenter <[email-masked]>; Ron Bonica <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]; 6man <[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ketan,

> On May 21, 2020, at 8:12 PM, Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>> wrote:

> From: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>

> To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 May 2020 00:32:03 -0400

Ketan, I am trying to figure out which documents you think were adopted 
and approved elsewhere to drive the 6man work on SRH.

I did find RFC 8354, which was a use case.  It is not a problem 
statement.  It is most definitely not an architecture.  The only 
architecture documents I can find are general SR documents.  Those did 
not justify a need for SRH.  And I (at least) did not object to SRH on 
the basis of that gap.

Yes, SRH normatively references 8402.  But 8402 does not drive any need 
for SRH.  In fact, the actual text references to SRH are fairly cursory. 
  (The most significant is some terminology.)

In fact, as far as I can tell, the ties are such that there is no 
evidence in the documents that SPRING had any say in SRH.  (the reality 
is more complex, I grant you.  But there was no formal approval or signoff.)

As far as I can tell, there was no formal approval of anything by SPRING 
that can be read as a request to 6man to work on SRH.  (Do remember that 
the SRH document was adopted by 6man in December of 2015.)  The network 
programming draft did not even appear at 00 until March of 2017, 15 
months later.

How, given this history, can you claim that CRH needs something more. 
We have operators asking for this.

Yours,
Joel

On 5/21/2020 11:53 PM, Ketan Talaulikar (ketant) wrote:
> 1) There is a WG (not 6man) that defines the problem statement, 
> use-cases and architecture that requires RH
> 
> 2) The 6man being the experts on IPv6 design, either take up the 
> document that specifies that RH (or even if it is done in another WG, 
> reviews it).
> 
> It is not in 6man charter nor expertise to take up (1) because CRH is 
> not purely IPv6 work. It is not meant for "Internet" but a specific 
> "limited domain". The SIDs that it introduces is a new "mapping ID" 
> concept. It is not an IPv6 address and neither it is MPLS. This is a 
> *_Routing_* Header and part of a new Source *_Routing_* solution.
> 
> Therefore, without (1) being made available to 6man, I believe that 
> working on (2) in 6man is to me a shortcutting of the IETF technical 
> review process (specifically of the *_Routing_* area in this case) for a 
> solution and does not provide the necessary reference for 6man to work on.
> 
> Why the rush?
> 
> I close my arguments.
> 
> Thanks,
> 
> Ketan
> 
> Cc: Bob Hinden <[email-masked]>; Brian Carpenter 
> <[email-masked]>; Ron Bonica <[email-masked]>; Chengli 
> (Cheng Li) <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Robert 
> Raszuk <[email-masked]>; [email-masked]; 6man <[email-masked]>
>  > On May 21, 2020, at 8:12 PM, Ketan Talaulikar (ketant) 
> <ketant=[email-masked] 
> <mailto:ketant=[email-masked]>> wrote:
> 
>  >
> 
>  > Hi Brian,
> 
>  >
> 
>  > My argument is not legalistic. I am not as experience in IETF work as 
> you and Bob are. But what I understand is that the reason why we have 
> these "legal" process of charters and BoF is to enable a proper 
> technical discussion with the right context and details of the proposal 
> presented for review of the community.
> 
>  >
> 
> There is no short cutting here.  The adoption call is to determine if 
> there is interest in the w.g. to take this work into 6man.   If it 
> becomes a w.g. draft, then the w.g. is responsible to decide what 
> happens next.
> 
>  > To: Ketan Talaulikar (ketant) <[email-masked] 
> <mailto:[email-masked]>>; Ron Bonica <[email-masked] 
> <mailto:[email-masked]>>; Chengli (Cheng Li) <[email-masked] 
> <mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked] 
> <mailto:[email-masked]>>; Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>>
> 
>  > Cc: [email-masked] <mailto:[email-masked]>; 6man <[email-masked] 
> <mailto:[email-masked]>>
> 
>  > If this addition was major, that would be true. But adding a new RH 
> type is well within the scope of maintenance, IMHO. We have already done 
> it quite recently.
> 
>  >
> 
>  > [email-masked] <mailto:[email-masked]>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 22 May 2020 05:20:50 +0000

Hi Joel,

I'll point you to RFC7855, RFC8355 and RFC8402 that cover both the data-planes for Spring. Then the RFC8354 which is focussed on SRv6. All this body of work along with a whole lot of discussion and brainstorming happening in the Spring WG provided the architecture, use-cases, applicability and requirements for SRH (RFC8754).

It may be so that many people in 6man focussed on only the IPv6 specific aspects as is their design expertise. But there were others (in 6man, Spring and other WGs) that were able to look at the solution in a holistic manner thanks to the body of work behind it.

Net-PGM builds on top of RFC8402 and RFC8754.

To give a real world analogy, let us understand what kind of a car we are trying to build (to carry goods/passengers or both and how much/many, what terrain it is meant for, what weather/environment conditions, how much speed/performance/fuel efficiency parameters required, etc.) before we start designing tyres for it.

Thanks,
Ketan 

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: 22 May 2020 10:02
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>; [email-masked]
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ketan, I am trying to figure out which documents you think were adopted and approved elsewhere to drive the 6man work on SRH.

I did find RFC 8354, which was a use case.  It is not a problem statement.  It is most definitely not an architecture.  The only architecture documents I can find are general SR documents.  Those did not justify a need for SRH.  And I (at least) did not object to SRH on the basis of that gap.

Yes, SRH normatively references 8402.  But 8402 does not drive any need for SRH.  In fact, the actual text references to SRH are fairly cursory. 
  (The most significant is some terminology.)

In fact, as far as I can tell, the ties are such that there is no evidence in the documents that SPRING had any say in SRH.  (the reality is more complex, I grant you.  But there was no formal approval or signoff.)

As far as I can tell, there was no formal approval of anything by SPRING that can be read as a request to 6man to work on SRH.  (Do remember that the SRH document was adopted by 6man in December of 2015.)  The network programming draft did not even appear at 00 until March of 2017, 15 months later.

Yours,
Joel

On 5/21/2020 11:53 PM, Ketan Talaulikar (ketant) wrote:
> review process (specifically of the *_Routing_* area in this case) for 
> a solution and does not provide the necessary reference for 6man to work on.
> 
> Why the rush?
> 
> I close my arguments.
> 
> Thanks,
> 
> Ketan
> 
> <[email-masked]>; Ron Bonica <[email-masked]>; 
> Chengli (Cheng Li) <[email-masked]>; Zafar Ali (zali) 
> <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]; 
> 6man <[email-masked]>
>  > My argument is not legalistic. I am not as experience in IETF work 
> as you and Bob are. But what I understand is that the reason why we 
> have these "legal" process of charters and BoF is to enable a proper 
> technical discussion with the right context and details of the 
> proposal presented for review of the community.
> 
>  >
> 
> type is well within the scope of maintenance, IMHO. We have already 
> done it quite recently.
> 
>  >
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 22 May 2020 05:23:58 +0000

I am thinking that the operators would be looking for the car and not the tyre?

Thanks,
Ketan

-----Original Message-----
From: Ketan Talaulikar (ketant) 
Sent: 22 May 2020 10:55
To: 'Joel M. Halpern' <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>; [email-masked]
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Joel,

Thanks,
Ketan 

-----Original Message-----
From: Joel M. Halpern <[email-masked]>
Sent: 22 May 2020 10:02
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>; [email-masked]
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Yours,
Joel

---

From: Andrew Alston <[email-masked]>
Date: Fri, 22 May 2020 09:15:24 +0000

Actually Ketan,

As an operator – I am looking for the tyre – I want the building block – because it allows me to both use what the vendors build on top of it – and to build my own stuff on top of it that is specific to my needs.

The tyre association is one such association – the brick is another – the brick was invented long before anyone created an architectural diagram to build a building.  CRH is a brick – that can be shaped to many purposes.

And as an operator – it is *exactly* what I want – without the dictates of what any vendor says I can do with it.

There are unique conditions in every operator environment – and if an operator is given the right bricks – and those bricks can be used to build something that is inter-operable across the vendors and within their specific domain – it is that building that gives the operator their competitive advantage.  If however, all operators are  handed a completed building – its much harder to build something that differentiates.

I must point out – in a world where we are seeing more and more white box technology – and where content providers are moving to building their own things pretty quickly – why do you think that is?  One reason I believe is because the requirements are not the same everywhere – and I have long believed that a standard should be such that an operator can take that standard – and use it within his specific domain to build on top of – and rather we have a standard brick such that the solutions that are built are portable – than every operator inventing their own bricks and nothing working together.

Again – the reason I support CRH – is because of the flexibility and simplicity it affords me as an operator – and because – we have specific use cases and things we wish to build on top of it – some of which – are pretty standard and happily in the public domain – other things – which are specific internally.  And I for one right now – am far more willing as an operator to pay for the bricks that let me build something that is competitive in the market than pay for fait accompli that is nothing more than the dictates for what vendors think I want.

And yes – I support the divorce of CRH for all things SPRING related – because the use cases beyond segment routing are multiple – and I have absolutely zero desire – plan – or anything else to use something like the PGM draft on my network and impose that level of overhead, complexity, overloading of the v6 address and what I view as a general corruption of the v6 architecture.  What I want – is a simple routing header – that I can build on – and that’s the end of the architecture that I want dictated to me.

Thanks

Andrew

From: ipv6 <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, 22 May 2020 08:24
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Thanks,
Ketan

-----Original Message-----
From: Ketan Talaulikar (ketant)
Sent: 22 May 2020 10:55
To: 'Joel M. Halpern' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Joel,

Thanks,
Ketan

-----Original Message-----
From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Sent: 22 May 2020 10:02
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Yours,
Joel

On 5/21/2020 11:53 PM, Ketan Talaulikar (ketant) wrote:
> From: Bob Hinden <[email-masked]<mailto:[email-masked]>>
> Sent: 22 May 2020 09:03
> To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
> Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; Brian Carpenter
> <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>;
> Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali)
> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> 6man <[email-masked]<mailto:[email-masked]>>
<mailto:ketant=[email-masked]%0b>> <mailto:ketant=[email-masked]>> wrote:
> > From: Brian E Carpenter <[email-masked]
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>>
> > To: Ketan Talaulikar (ketant) <[email-masked]
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>>; Ron Bonica <[email-masked]
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>>; Chengli (Cheng Li) <[email-masked]
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>>; Robert Raszuk <[email-masked]
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>>
>
> > Cc: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; 6man <[email-masked]
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>>
> > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>
> > https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>
>
> [email-masked]<mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------

---

From: Andrew Alston <[email-masked]>
Date: Fri, 22 May 2020 09:24:49 +0000

Just as a followup – which I think illustrates my point here.

https://blogs.cisco.com/sp/cisco-goes-sonic-on-new-networking-platforms

If operators wanted fait accompli – why is it that Cisco – and other vendors – are starting to provide ASIC based API’s such that cloud providers and operators can do what they need on devices – rather than the dictates of vendors?  I think the very fact that the above article exists – illustrates the desire for simple building blocks.

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Andrew Alston
Sent: Friday, 22 May 2020 12:15
To: Ketan Talaulikar (ketant) <ketant=[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Actually Ketan,

Thanks

Andrew

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, 22 May 2020 08:24
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Thanks,
Ketan

-----Original Message-----
From: Ketan Talaulikar (ketant)
Sent: 22 May 2020 10:55
To: 'Joel M. Halpern' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Joel,

Thanks,
Ketan

-----Original Message-----
From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Sent: 22 May 2020 10:02
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Yours,
Joel

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 May 2020 02:52:28 -0300

> To give a real world analogy, let us understand what kind of a car we are trying to build (to carry goods/passengers or both and how much/many, what terrain it is meant for, what weather/environmen…

Continuing with your analogy, it would seem to me that in the process, 
Net-PGM decided to break the roads and ditch traffic rules so that their 
"new" vehicle could run faster, while ignoring that other folks and 
vehicles need those very same roads to be safe and reliable.

P.S.: Sorry, I couldn't help it.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 May 2020 10:35:46 -0400

None of those documents drive the need for SRv6.    Even the problem 
statement doesn't really geet us there.

More importantly, SRH does not fully comply with those documents.   It 
has fields that are unrelated to those documents.  Heck, it still has 
the tag field that many of us are unable to understand.  And it has a 
TLV that has no meaningful use (the authentication use is internally 
inconsistent, as was discussed on the list.)  While wew objected to 
various parts on the substance, the fact that SRH is meant as a building 
block to support things beyond the SPRIGN archtiecture was not an objection.

Architectures are the closest the IEtF comes to building solutions. 
They are arguably not very useful.  MPLS, for example meets both the 
base MPLS architecture and the SPRING architecture.  And several 
different VPN architectures.

CRH can be used to meet the SPRING archtiecture.  It can also, has been 
clearly stated, be used in other ways.  There is not "an" architecture 
for using CRH.

And there was not "an" architecture for using SRH.  If there ere, we 
would have gotten the extraneous parts removed.

Yours,
Joel

On 5/22/2020 1:20 AM, Ketan Talaulikar (ketant) wrote:
>> <mailto:[email-masked]>>
>>
>>   > Sent: 22 May 2020 04:18
>>

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 22 May 2020 15:21:05 +0000

The “mapping ID” indeed needs to be carefully explored, which may cause serious operational issue considering such a large number of local FIB entries imposed by CRH.

Shuping

From: ipv6 [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, May 22, 2020 11:53 AM
To: Bob Hinden <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Bob,

Why the rush?

I close my arguments.

Thanks,

Ketan

-----Original Message-----
From: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Sent: 22 May 2020 09:03
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; Brian Carpenter <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ketan,

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 22 May 2020 15:31:50 +0000

Hi, 

To me all the discussions happened here are about a clear justification required for a I-D. 

Best regards, 
Shuping 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, May 22, 2020 10:36 PM
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

More importantly, SRH does not fully comply with those documents.   It 
has fields that are unrelated to those documents.  Heck, it still has the tag field that many of us are unable to understand.  And it has a TLV that has no meaningful use (the authentication use is internally inconsistent, as was discussed on the list.)  While wew objected to various parts on the substance, the fact that SRH is meant as a building block to support things beyond the SPRIGN archtiecture was not an objection.

Architectures are the closest the IEtF comes to building solutions. 
They are arguably not very useful.  MPLS, for example meets both the base MPLS architecture and the SPRING architecture.  And several different VPN architectures.

CRH can be used to meet the SPRING archtiecture.  It can also, has been clearly stated, be used in other ways.  There is not "an" architecture for using CRH.

And there was not "an" architecture for using SRH.  If there ere, we would have gotten the extraneous parts removed.

Yours,
Joel

On 5/22/2020 1:20 AM, Ketan Talaulikar (ketant) wrote:
> evidence in the documents that SPRING had any say in SRH.  (the 
> reality is more complex, I grant you.  But there was no formal 
> approval or signoff.)
> 
>> review process (specifically of the *_Routing_* area in this case) 
>> for a solution and does not provide the necessary reference for 6man to work on.
>>
>> Why the rush?
>>
>> I close my arguments.
>>
>> Thanks,
>>
>> Ketan
>>
>>   > My argument is not legalistic. I am not as experience in IETF 
>> work as you and Bob are. But what I understand is that the reason why 
>> we have these "legal" process of charters and BoF is to enable a 
>> proper technical discussion with the right context and details of the 
>>   >> “It is not chartered to develop major changes or additions to 
>> the
>> IPv6 specifications.”
>>
>>   >
>>
>>   > If this addition was major, that would be true. But adding a new 
>> RH type is well within the scope of maintenance, IMHO. We have 
>> already done it quite recently.
>>
>>   >
>>
>>   > In any case, legalistic arguments about WG charters are really 
>> not how we should take technical decisions.
>>
>>   >
>>
>>   > Regards
>>
>>   >    Brian
>>
>>   >
>>
>>   >
>>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 22 May 2020 08:34:39 -0700

Ketan,

There was also a whole lot of discussion that took place in 6man when
SRH draft was being worked on. There were fundamental aspects of SRH
that were questioned such as: why does SRH require its own TLVs and
why aren't Destination Options before the Routing Header sufficient,
why does SRH need flags and tag field, why does it require its own
header authentication instead of just relying on AH (which in fact SRH
actually breaks AH), what are the mutability requirements of the
header. There were also questions about the overhead of carrying lists
of 128 bit addresses, as well as implications of using IPv6 addresses
as SIDs. Of course, SRH motivated the whole discussion about extension
header insertion and deletion.

Some of these questions were answered, some were not and the draft
advanced with noted objections-- but, in all those discussions I don't
believe any of these questions were answered by someone just referring
us to an architecture or requirements document.

Tom

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 22 May 2020 23:54:46 +0800

Hi, Andrew and all:

Is  using the “Routing Header” to maneuver the path of packet a good idea?  

>From the viewpoint of the service provider, if we depend on the central controller/PCE to assure the QoS of application, we should simplify the network design and the network device.

Currently, both SRH and CRH deployment requires the presence of SDN controller/PCE, but the network/device complexity is not decreased.  How operator can benefit from the adoption of these technologies?

You have also mentioned the cloud provider. What their requirements is the openness/standard API from the device, this can give the most flexibility for network programming. 

Why we don’t  dive into this direction?  There are several NorthBound interfaces/protocols exist in IETF standard.

For CRH and SRH, I think there are some similarity between them. CRH does not conflict with the IPv6 address, but requires the map table exist. Many experts will dispute again the similar problem.

Is CRH the brick that cloud provider want?

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Andrew Alston
发送时间: 2020年5月22日 17:25
收件人: Andrew Alston; Ketan Talaulikar (ketant); Joel M. Halpern
抄送: [email-masked]; [email-masked]; 6man
主题: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Thanks

Andrew

Actually Ketan,

Thanks

Andrew

Thanks,
Ketan

-----Original Message-----
From: Ketan Talaulikar (ketant) 
Sent: 22 May 2020 10:55
To: 'Joel M. Halpern' <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>; [email-masked]
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Joel,

Thanks,
Ketan 

-----Original Message-----
From: Joel M. Halpern <[email-masked]>
Sent: 22 May 2020 10:02
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>; [email-masked]
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Yours,
Joel

On 5/21/2020 11:53 PM, Ketan Talaulikar (ketant) wrote:
> <ketant=[email-masked] <mailto:ketant=[email-masked]%0b> 
> > From: Brian E Carpenter <[email-masked]  <mailto:[email-masked]%20%0b> 
> > To: Ketan Talaulikar (ketant) <[email-masked]  <mailto:[email-masked]%20%0b> 
> <mailto:[email-masked]>>; Ron Bonica <[email-masked]  <mailto:[email-masked]%20%0b> 
> <mailto:[email-masked]>>; Chengli (Cheng Li) <[email-masked]  <mailto:[email-masked]%20%0b> 
> <mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]  <mailto:[email-masked]%20%0b> 
> <mailto:[email-masked]>>; Robert Raszuk <[email-masked]  <mailto:[email-masked]%20%0b> 
> > Cc: [email-masked] <mailto:[email-masked]>; 6man <[email-masked]  <mailto:[email-masked]%20%0b> 
> <mailto:[email-masked]>>
>

---

From: Andrew Alston <[email-masked]>
Date: Fri, 22 May 2020 16:26:24 +0000

Hi Ajun,

I cannot speak for what the cloud providers want – and will not attempt to put words in their mouths.  But, let me attempt to address this from my perspective as the employee of an operator.

The way I see it – operators are seeing declining revenues in bandwidth sales – have been for 20 years.  Being just an ISP – no longer gives the edge it once did – and while in Africa in a developing market such as the one I operate in, we’ve probably had a slower curve in the pure bandwidth market – the fact is that operators need to be able to differentiate themselves.  What this means is, building services on top of the infrastructure they have.  Effectively, I view the operator of the future as almost an over the top player on top of the hardware and fiber and infrastructure that underpins those services.

Now – if said operator goes to the market and buys a fully completed solution – that same solution – is always available to their competition.  Where the true differentiation comes in – will happen at multiple levels, in the service and support and resilience of the network – in the customer service – and in innovative products and services.  I believe that the operator that can build those products and services from the base building blocks – gives themselves an advantage.  Being able to steer traffic in granular ways opens itself to a world of possibilities.  And be that through SR-MPLS – be that using the CRH – or be that via SRv6 – each has positives and negatives and advantages and disadvantages.  I would argue that while we are very heavy users of SR-MPLS – and SR-MPLS will certainly have a strong future in our network – that does not negate the place that something like CRH has is our minds and in fact we have built some very interesting things on top of CRH which we are testing – the details of which I am sadly not free to disclose.

Now – if I want to innovate like this – and have my ideas and thoughts heard, I need these building blocks – because as I build on top of them, be it in production or in a lab environment – that leaves me the freedom to take what I have built and either keep it internal, or – where applicable – take those ideas and that intellectual property, and open it up to the rest of the world and let the market decide if they want it.  That expands the innovation base beyond the ideas and thoughts of a limited few vendors.

I argue strongly that to build a strong and competitive future, particularly in a developing market – a market which up until this point has had very very little influence on the technologies they run – requires people to be able to think out of the box – and use the tools available.  Some will take advantage of this paradigm – some will continue to turn to the vendors for every line of config – I believe that those who can use the lower level building blocks – are the ones that will win out – because innovation drives sustainability and the future.

Is CRH the only brick I want?  No – there are many of them – and there are many ideas – this is one – and you cannot build a house with a single brick – but – it is a brick that I view at least for us, operating in 15 countries, as a brick that is critical to some of the plans we have.

So – is this a brick we want? Yes.  Do I want every use case – every architecture that I use this brick for dictated to me by a vendor? Certainly not.  And I will finish this rather long email with this thought – the vendor that is prepared to work with the customers to innovate and help create the building blocks – and then work the customer as the customer innovates – is always going to end up finishing ahead of the vendor that tries to shove their ideas – which are formulated in offices thousands of miles from the on the ground realities of certain parts of the world – down the operators throats.

Hence – yes – I like simple building blocks

Andrew

From: spring <[email-masked]> On Behalf Of Aijun Wang
Sent: Friday, 22 May 2020 18:55
To: Andrew Alston <[email-masked]>; 'Ketan Talaulikar (ketant)' <ketant=[email-masked]>; 'Joel M. Halpern' <[email-masked]>
Cc: [email-masked]; [email-masked]; '6man' <[email-masked]>
Subject: [spring] 答复: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi, Andrew and all:

Best Regards.

Aijun Wang
China Telecom

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Andrew Alston
发送时间: 2020年5月22日 17:25
收件人: Andrew Alston; Ketan Talaulikar (ketant); Joel M. Halpern
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 6man
主题: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

https://blogs.cisco.com/sp/cisco-goes-sonic-on-new-networking-platforms<https://blogs.cisco.com/sp/cisco-goes-sonic-on-new-networking-platforms>

Thanks

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Andrew Alston
Sent: Friday, 22 May 2020 12:15
To: Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Actually Ketan,

Thanks

Andrew

Thanks,
Ketan

-----Original Message-----
From: Ketan Talaulikar (ketant)
Sent: 22 May 2020 10:55
To: 'Joel M. Halpern' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Joel,

Thanks,
Ketan

-----Original Message-----
From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Sent: 22 May 2020 10:02
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Yours,
Joel

<mailto:ketant=[email-masked]%0b>> <mailto:ketant=[email-masked]>> wrote:
> > From: Brian E Carpenter <brian.e.carpenter@gmail..com
> > ....> It is the 6man charter that precludes it from defining a new
> Source Routing solution..
>

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Sat, 23 May 2020 00:22:19 +0000

Hi,

Please see inline.

--------------------------------------------------
彭书萍 Peng Shuping
Mobile: +86-18210364128<tel:+86-18210364128>(优先)
Email: [email-masked]<mailto:[email-masked]>

发件人：Aijun Wang <[email-masked]>
收件人：'Andrew Alston' <[email-masked]>;'Ketan Talaulikar (ketant)' <ketant=[email-masked]>;'Joel M. Halpern' <[email-masked]>
抄 送：rtg-ads <[email-masked]>;spring <[email-masked]>;'6man' <[email-masked]>
时 间：2020-05-22 23:55:46
主 题：[spring] 答复: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi, Andrew and all:

[Shuping] Protocols are simplified. Only need to care about IGP and BGP.

[Shuping] PCEP and BGP can be taken as the standard API of an SRv6 network, by which you can program your network.

[Shuping] SRv6 into DC is also appealing since it enables end-to-end true network and cloud convergence.

Best Regards.
Aijun Wang
China Telecom

Thanks,
Ketan

-----Original Message-----
From: Ketan Talaulikar (ketant)
Sent: 22 May 2020 10:55
To: 'Joel M. Halpern' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Joel,

Thanks,
Ketan

-----Original Message-----
From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Sent: 22 May 2020 10:02
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Yours,
Joel

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sun, 24 May 2020 05:42:16 +0000

Hi Joel.

I believe the focus of the adoption call is CRH and that too in the context outside the SRm6. So I am not trying to debate SRH or SRv6 at this point - we can do that separately not to mix things up.

I am looking for explanation of the "other ways" that CRH can be used (i.e. those outside the Spring architecture). I am trying to understand from the authors what would be the applicability of that solution, it's use-cases and it's requirements. That is what, I believe, will help us evaluate the CRH proposal in the context of this working call. That will help us answer these questions like the scope of the SID, 32-bit or 16-bit or something else and what the CRH-FIB is going to turn out like.

Note that we are introducing a new CRH-FIB based on some vague definition of "SID" in the IPv6 Forwarding Architecture here. I've seen comparison of these SIDs (mapping IDs) to MPLS labels, if that so - isn't it a significant change to IPv6 Routing that needs more clarity? The CRH proposal may end up introducing a new form of MPLS into IPv6 - something that needs very close and careful consideration.

Thanks,
Ketan

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: 22 May 2020 20:06
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>; [email-masked]
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Yours,
Joel

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sun, 24 May 2020 05:44:04 +0000

Hi Tom,

We've seen a very long and exhaustive debate and review on SRH in the 6man WG. I am not sure how bringing that up helps answer the questions raised during the CRH adoption.

Thanks,
Ketan 

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: 22 May 2020 21:05
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ketan,

There was also a whole lot of discussion that took place in 6man when SRH draft was being worked on. There were fundamental aspects of SRH that were questioned such as: why does SRH require its own TLVs and why aren't Destination Options before the Routing Header sufficient, why does SRH need flags and tag field, why does it require its own header authentication instead of just relying on AH (which in fact SRH actually breaks AH), what are the mutability requirements of the header. There were also questions about the overhead of carrying lists of 128 bit addresses, as well as implications of using IPv6 addresses as SIDs. Of course, SRH motivated the whole discussion about extension header insertion and deletion.

Some of these questions were answered, some were not and the draft advanced with noted objections-- but, in all those discussions I don't believe any of these questions were answered by someone just referring us to an architecture or requirements document.

Tom

> I did find RFC 8354, which was a use case.  It is not a problem statement..  It is most definitely not an architecture.  The only architecture documents I can find are general SR documents.  Those did not justify a need for SRH.  And I (at least) did not object to SRH on the basis of that gap.
>
> As far as I can tell, there was no formal approval of anything by SPRING that can be read as a request to 6man to work on SRH.  (Do remember that the SRH document was adopted by 6man in December of 2015.)  The network programming draft did not even appear at 00 until March of 2017, 15 months later..
>
> > document that specifies that RH (or even if it is done in another 
> > WG, reviews it).
> >
> > It is not in 6man charter nor expertise to take up (1) because CRH 
> > is not purely IPv6 work. It is not meant for "Internet" but a 
> > specific "limited domain". The SIDs that it introduces is a new "mapping ID"
> > <[email-masked]>; Robert Raszuk <[email-masked]>; 
> > [email-masked]; 6man <[email-masked]>
> > work as you and Bob are. But what I understand is that the reason 
> > why we have these "legal" process of charters and BoF is to enable a 
> > proper technical discussion with the right context and details of 
> > the proposal presented for review of the community.
> >
> >  >
> >
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 03:32:32 +0000

Ketan,

Please consider an operator who:

- Wants a way to steer IPv6 packets through a specified path that includes many nodes (>8)
- Does not want any of the following:
	- A new VPN encapsulation technique
	- A new service function chaining technique
	- Network programming
	- MPLS and uSID
	- To encoding instructions in IPv6 addresses.

These operators want a compact routing header, nothing more.

                                                                           Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Sunday, May 24, 2020 1:42 AM
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[SNIP]

[SNIP]
------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 25 May 2020 11:18:07 +0200

Hi Ron,

Your below list looks like custom made set of RFP requirements to eliminate
any other vendor or any other solution to solve the problem at hand rather
then rational list of requirements.

Btw please observe that most if not all of the below "Does not want" are
optional in any solution. If some one "Does not want" then someone just
does not enable them.

Rgs,
R.

PS.  Would you not buy a phone which supports optional "haptic touch" just
because you would never master how to use it or would you buy it anyway
and simply not enable it while enjoy 99 other useful features ?

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 25 May 2020 09:20:39 +0000

Hi Ron,

Thanks for that clarification.

I note that you are not anymore saying "Are not interested in SR" like you had mentioned before the WG adoption call : https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/

So, would it be fair to say that the operator that you are referring to below, wishes to deploy a Traffic Engineering solution using a subset of Segment Routing (i.e. a reduced portion of Spring Architecture) that only supports prefix and adjacency SIDs as indicated by the two "forwarding methods" that are referred to in draft-bonica-6man-comp-rtg-hdr?

Thanks,
Ketan

-----Original Message-----
From: Ron Bonica <rbonica=[email-masked]> 
Sent: 25 May 2020 09:03
To: Ketan Talaulikar (ketant) <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ketan,

                                                                           Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Sunday, May 24, 2020 1:42 AM
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[SNIP]

[SNIP]

---

From: Sander Steffann <[email-masked]>
Date: Mon, 25 May 2020 12:10:22 +0200

Hi Robert,

> Your below list looks like custom made set of RFP requirements to eliminate any other vendor or any other solution to solve the problem at hand rather then rational list of requirements.

My main customer (an ISP in NL) would fit exactly in the list that Ron sent. They want a simple solution that they can understand and manage, that works over IPv6. Whether the path will include many nodes (>8) is not known at this point, but they want something that can support it in the future.

So the list of requirements isn't that strange.

Cheers,
Sander

---

From: [email-masked]
Date: Mon, 25 May 2020 12:30:58 +0200

Sander,

> So the list of requirements isn't that strange.

That CRH is simple is a bit like claiming that MPLS is simple just because the header has few fields.
I think you would be hard pressed to substantiate that any solution here is particularly simpler than any other. But you are welcome to try.

Everyone claims to want a simple solution, funnily enough the end result is usually the opposite. The words "simple" and "source routing" are oxymorons.
Let's leave the marketing out of this.

Ole

---

From: Sander Steffann <[email-masked]>
Date: Mon, 25 May 2020 15:11:36 +0200

Hi,

> I think you would be hard pressed to substantiate that any solution here is particularly simpler than any other. But you are welcome to try.

As a user I usually find:
Fewer fields -> fewer moving bits -> simpler to understand and debug

> Let's leave the marketing out of this.

It is indeed all more complex than simple SRC->DST routing.

Cheers,
Sander

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 15:43:35 +0000

Ketan,

It would not be fair to say that these operators  "wish to deploy a Traffic Engineering solution using a subset of Segment Routing". 

It would be fair to say that these operators  "wish to deploy IPv6 Traffic Engineering".  Some of these operators don't care about SR. Some are actively averse to SRv6. All they want is a Routing header.

                                                                 Ron

-----Original Message-----
From: Ketan Talaulikar (ketant) <ketant=[email-masked]> 
Sent: Monday, May 25, 2020 5:21 AM
To: Ron Bonica <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Ron,

I note that you are not anymore saying "Are not interested in SR" like you had mentioned before the WG adoption call : https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$

Thanks,
Ketan

-----Original Message-----
From: Ron Bonica <rbonica=[email-masked]>
Sent: 25 May 2020 09:03
To: Ketan Talaulikar (ketant) <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ketan,

                                                                           Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Sunday, May 24, 2020 1:42 AM
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[SNIP]

[SNIP]

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 15:49:23 +0000

Ole,

When commenting on list, could you indicate whether hats are on or off?

                    Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, May 25, 2020 6:31 AM
To: Sander Steffann <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; 6man <[email-masked]>; [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Sander,

Ole

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 25 May 2020 17:58:42 +0200

Hi Ron,

> It would be fair to say that these operators  "wish to deploy IPv6 Traffic
> Engineering".  Some of these operators don't care about SR. Some are
> actively averse to SRv6. All they want is a Routing header.
>

How about all of the above minus need for new routing header and zero
overhead (except one IPv6 encapsulation) with far better scaling properties
and no dependency on number of transit hops ?

Hint: Reference based Routing RbR

Do you think that if someone ships RbR there would be even single advantage
to use CRH ?

Thank you,
R.

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 May 2020 18:22:29 +0200

> On 25 May 2020, at 17:49, Ron Bonica <[email-masked]> wrote:
> 
> Ole,
> 

And that is important to you for this particular message because?

Ole

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 16:27:58 +0000

So that I will know whether I am allowed to reply.

                                       Ron

-----Original Message-----
From: Ole Troan <[email-masked]> 
Sent: Monday, May 25, 2020 12:22 PM
To: Ron Bonica <[email-masked]>
Cc: Sander Steffann <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]; 6man <[email-masked]>; [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ole

---

From: [email-masked]
Date: Mon, 25 May 2020 18:40:55 +0200

Ron,

[changed subject, as this seems of little relevance]

> So that I will know whether I am allowed to reply.

Wearing a chair's hat has never stopped anyone from replying before.

For formal 6man communication Bob and I generally sign with "Best regards, Bob and Ole, 6man co-chairs".
Unless that signature is there you can assume I post as an individual.

> Juniper Business Use Only

The slight hostility I detect in your replies, I suspect has more to do with the particular employer hat I also wear as opposed to the chair hat.

Ole

---

From: Andrew Alston <[email-masked]>
Date: Mon, 25 May 2020 16:42:32 +0000

I think a better question would be – not if hats are on or off – but which hat – the employee of a vendor hat?  The WG chair hat? The CoC hat? The “In personal capacity” hat?

Like Ron and others – I’m kinda curious here

Andrew

From: spring <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Monday, 25 May 2020 at 18:51
To: "[email-masked]" <[email-masked]>, Sander Steffann <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 6man <[email-masked]>, "Ketan Talaulikar (ketant)" <[email-masked]>, Robert Raszuk <[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ole,

Ron

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Monday, May 25, 2020 6:31 AM
To: Sander Steffann <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; 6man <[email-masked]>; [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Sander,

Ole

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 16:53:42 +0000

Ole,

OK, the I can reply, contributor to contributor.

Two reasonable people can argue about complexity metrics. Sometimes, these arguments make sense.

Sometimes, metrics aren't required. By any measure, my bicycle is a more simple machine than my car.

However, I think that it is unfair to say that:

- All discussion of simplicity is marketing
- Any discussion of simplicity visa vis source routing is an oxymoron.

                                                                                   Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, May 25, 2020 12:41 PM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>; [email-masked]
Subject: What's the colour of the hat (was: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH)

Ron,

Ole

---

From: Sander Steffann <[email-masked]>
Date: Mon, 25 May 2020 18:54:59 +0200

Hi,

> The slight hostility I detect in your replies, I suspect has more to do with the particular employer hat I also wear as opposed to the chair hat.

Sigh. Who calls a WG chair to order when making unsubstantiated accusations in reply to a simple request?
I find Ole's behaviour to become very unproductive and unbecoming of a chair…

Can we please get back to civil and cooperative behaviour please?

Cheers,
Sander

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 17:17:13 +0000

Ole,

No hostility. It was strictly procedural.

I consider you to be a valued friend. In 100 years, nobody will care about any of this.

                                                 Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, May 25, 2020 12:41 PM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>; [email-masked]
Subject: What's the colour of the hat (was: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH)

[snip]

[snip]

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 25 May 2020 19:46:36 +0200

Sander,

For the record I do not find anything what Ole said to be unproductive. In
my view he is leading this group together with Bob very well being neutral
and unbiased from the perspective of the affiliation.

Maybe instead of teaching everyone good manners you could for a change
start using the list to discuss technology related matters ?

R.

On Mon, May 25, 2020 at 6:55 PM Sander Steffann <[email-masked]> wrote:

> Hi,
>
> > The slight hostility I detect in your replies, I suspect has more to do
> with the particular employer hat I also wear as opposed to the chair hat.
>
> Sigh. Who calls a WG chair to order when making unsubstantiated
> accusations in reply to a simple request?

---

From: Srihari Sangli <[email-masked]>
Date: Tue, 26 May 2020 05:59:52 +0000

+1

srihari…

On 25/05/20, 10:13 PM spring on behalf of Andrew Alston from [email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]> said >

Andrew

Ole,

Ron

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Monday, May 25, 2020 6:31 AM
To: Sander Steffann <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; 6man <[email-masked]>; [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Sander,

Ole

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!WKwYnERKyJMlVytSsogP5BgL6Z9jJxS7Tznh8McM2BLglnrMEh9WOgLOtRtd_Qs$>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 28 May 2020 11:46:28 +0000

Hi Ron,

Some of the operators may not care about the SR name, but it is clear to me that the proposal in the CRH draft is a subset of Segment Routing (i.e. a reduced portion of Spring Architecture) that only supports prefix and adjacency SIDs as indicated by the two "forwarding methods".

https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#section-4

   o  Forward the packet to the next-hop along the least-cost path to >>> Prefix SID
      the next segment endpoint.

   o  Forward the packet through a specified interface to the next >>> Adjacency SID
      segment endpoint.

Given the use of mapping IDs and mapping FIB, the proposal is comparable more to SR-MPLS than SRv6. It is better to do a holistic analysis of any proposal such as CRH that is introducing an MPLS label like mapping construct into IPv6 architecture - doing so should be considered as a significant change to IPv6.

Thanks,

Ketan

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

From: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>

Sent: 25 May 2020 21:14

To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>

Ketan,

                                                                 Ron

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

From: Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>

To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>

Hi Ron,

I note that you are not anymore saying "Are not interested in SR" like you had mentioned before the WG adoption call : https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$>

Thanks,

Ketan

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

From: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>

Sent: 25 May 2020 09:03

To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>

Ketan,

        - Network programming

        - MPLS and uSID

                                                                           Ron

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

[SNIP]

[SNIP]

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 May 2020 09:47:06 -0300

On 28/5/20 08:46, Ketan Talaulikar (ketant) wrote:
[...]
> 
> Some of the operators may not care about the SR name, but it is clear to 
> me that the proposal in the CRH draft is a subset of Segment Routing 
> (i.e. a reduced portion of Spring Architecture) 

I find it kind of amusing when folks suggest that source routing routing 
is a spring or segment-routing thing, when all IPv4, CLNP, and IPv6 
(with RHT0) have supported some for of it for *ages*, and all predate 
segment routing and the work of Spring wg.

CRH seems to me as a variant of RHT0, where rather than employing 
128-bit addresses, they employ labels that are indirectly mapped to 
addresses, thus reducing the overhead in the packets themselves. With 
the obvious consequence that you need intermediate systems to support 
CRH (since otherwise you wouldn't be able to map the ID/label into an 
actual IPv6 address).

The above comment is meant neither in favor nor against CRH, but rather 
a reminder that source routing existed well before Spring, RFC8754, and 
others, and, as a result, well before Spring monopoly on routing headers 
(?) was declared.

Thanks,

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Thu, 28 May 2020 14:34:39 +0000

Hi Ron,

After reading through many mails related to CRH in list, I found all CRH-SIDs (allocated to prefix-sid <loosely forwarding>and Adj-sid<strict forwarding>) are of local significance in fact, its operation actually is not same as MPLS Label nor SR-MPLS label (such as domain-wide prefix SID/label), all CRH-SIDs are locally allocated by node itself based on local FIB6, independent of other CRH-SID allocated by other nodes in CRH domain; so every node (Maybe except  ingress PE of CRH domain)  has no useful to learn other SIDs allocated by other nodes by IGP-extension advertising. Its deployment must have controller (considering dynamic mechanism), the controller learn all CRH-SIDs from each node to program the source path under path calculation requirement from ingress PE.

I suggested you should describe more detail about how to create CRH-SID entry (in CRH-FIB) in this CRH draft, is it based on local FIB6, if it is, how to do synchronization between CRH-FIB and FIB6?
Above is my understanding, if not right,pls correct me.

Wang Weibin

From: ipv6 <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: 2020年5月28日 19:46
To: Ron Bonica <rbonica=[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Ron,

Thanks,

Ketan

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

Sent: 25 May 2020 21:14

Ketan,

                                                                 Ron

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

Hi Ron,

Thanks,

Ketan

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

Sent: 25 May 2020 09:03

Ketan,

        - Network programming

        - MPLS and uSID

                                                                           Ron

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

[SNIP]

[SNIP]

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 28 May 2020 10:56:32 -0400

On Thu, May 28, 2020 at 7:46 AM Ketan Talaulikar (ketant) <ketant=
[email-masked]> wrote:

> me that the proposal in the CRH draft is a subset of Segment Routing (i.e.
> a reduced portion of Spring Architecture) that only supports prefix and
> adjacency SIDs as indicated by the two "forwarding methods".
>
>
>
>    o  Forward the packet to the next-hop along the least-cost path to *>>>
> Prefix SID*
>
>    o  Forward the packet through a specified interface to the next *>>>
> Adjacency SID*
>
>       segment endpoint.
>
>
>
> Given the use of mapping IDs and mapping FIB, the proposal is comparable
> more to SR-MPLS than SRv6. It is better to do a holistic analysis of any
> proposal such as CRH that is introducing an MPLS label like mapping
> construct into IPv6 architecture - doing so should be considered as a
> significant change to IPv6.
>
>  Gyan> Ketan - you are misunderstanding the CRH architecture.  It uses the
> IPv6 data plane so is a variant of SRV6 and not SR-MPLS.
>
SR-MPLS reused then MPLS  data plane to create  fec bindings and uses label
> stacking for steering cSPF static lsp using the MPLS forwarding plane.
>
Operators that want CRH don’t want to go backwards and use SR-MPLS and have
the baggage of MPLS data plane as in general these are green field
operators use cases.

SR-MPLS he it’s place and where it shines and works well is for brown field
operators with existing MPLS LDPv4 deployments it’s a simple migration to
SR-MPLS.

For operators that already have an IPV6 core  or are running MPLS LDPv6
brown field deployments,  then then SRV6 or now CRH or SRM6 are the viable
options.

    CRH introduces a new RH similar to RH0 or any of      the other new RH
introduces for simple source routing which has been around since IPv4.

> CRH does not use the segments in the RH  to build the actual static hop by
> hop steered path as does SR-MPLS via SRGB block label stacking.
>

     Remember CRH is just another IPV6 Routing header.  However now instead
of copying the routing  segment into the segment list to the IPv6
destination address as done with SRV6 their is one simple extra step.  A
CRH-FIB entry is created manually that is referenced by the routing segment
and that entry is the IPv6 address that is copied to the next hop
destination address to steer the packet hop by hop.

By not storing the IPV6 address in the CRH RH you save all the problem with
MSD(Maximum SID depth) issues that occur in with SRv6 which really makes
SRV6 not viable for long strict SR-TE paths using adjacency sid that are
more then a few hops due to MSD issue.  SRV6 has its complex programming
with end prefix sid and end.x adjacency sid instantiations overhead that
makes SRV6 not viable for operators that don’t want to add in all the
additional complexity of the many compression drafts 6+ that exist today to
resolve the MSD issue.

Speaking from an operator perspective, representing Verizon a Tier 1
carrier, we have use cases as other carriers for intra domain very very
long static per VRF coloring of L3 vpn instantiated strict paths using
SR-TE and flexalgo.  However SRv6 by itself does not stack up and requires
use of the compression techniques for SR-TE per VRF coloring.

Unfortunately for SRV6 it failed to start out of the gate natively and
could not deliver on per VRF coloring of long strict paths using SR-TE
binding SID which is what the industry has been clamoring for.

The major benefit for CRH is that natively it can have very very long
strict hop by hop steered paths without requiring additional complexity
component for compression techniques to make it work as does SRV6.

SRv6 has its place in the industry and works well with  short cSPF paths
using prefix sid and staying away from hop by hop long strict explicit
paths.  And if you are willing to add the complexity of one of the many
compression techniques then so be it and that makes SRV6 viable as well as
an option for operators requiring long strict paths.

For Verizon we would use SRM6 as it is the full blown version of CRH as it
has the IGP extensions and supports SR-TE binding sid.

For the many use cases where a very long strict hop by hop path is required
and you want to use your existing IPv6 data plane, then CRH is the answer
as it is a low overhead means of source routing and works plug-n-play out
of the box using the IPv6 data plane.  No need for any of the many
compression techniques as required by SRv6 for building strict paths.

CRH is no different then RFC 8138 RH used for 6lo devices.

https://tools.ietf.org/html/rfc8138

The comments related to SR-MPLS over IPv6 RFC 8663 using tunneling
techniques RFC 4023 MPLS over GRE in IPinIP w/o GRE using IPv6 outer header
similar to Universal SID draft used for SRV6 to SR-MPLS interworking.
There are use case for using RFC 8663 but that in my mind would be for
Mirsky Universal SID interoperability use cases where you require
interworking between SR-MPLS and SRv6 the tunneling of SR-MPLS in outer
IPV6 header with RFC 8663.

https://datatracker.ietf.org/doc/html/draft-mirsky-6man-unified-id-sr-06

This is completely different from CRH.  If you need interworking you use
RFC 8663 with Mirsky draft or if you need a very simple low overhead
technique for source routing capability that works right out of the box
then CRH is the answer.

Kind Regards

> It would not be fair to say that these operators  "wish to deploy a
> Traffic Engineering solution using a subset of Segment Routing".
>
>
>
> To: Ron Bonica <[email-masked]>; Joel M. Halpern <[email-masked]
> >
>
> I note that you are not anymore saying "Are not interested in SR" like you
> had mentioned before the WG adoption call :
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$>
>
>
>
> So, would it be fair to say that the operator that you are referring to
> below, wishes to deploy a Traffic Engineering solution using a subset of
> Segment Routing (i.e. a reduced portion of Spring Architecture) that only
> supports prefix and adjacency SIDs as indicated by the two "forwarding
> methods" that are referred to in draft-bonica-6man-comp-rtg-hdr?
>
>
>
> Thanks,
>
> Ketan
>
>
>
> I am looking for explanation of the "other ways" that CRH can be used
> (i.e. those outside the Spring architecture). I am trying to understand
> from the authors what would be the applicability of that solution, it's
> use-cases and it's requirements. That is what, I believe, will help us
> evaluate the CRH proposal in the context of this working call. That will
> help us answer these questions like the scope of the SID, 32-bit or 16-bit
> or something else and what the CRH-FIB is going to turn out like.
>
>
>
>
>
> [SNIP]
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Ron Bonica <[email-masked]>
Date: Thu, 28 May 2020 15:11:11 +0000

Ketan,

Neither of these forwarding methods are unique to SR. In Section 3.1 of RFC 791, you will see that IPv4 had a Strict Source Route Option and a Loose Source Route Option. These predate SR by roughly twenty-five years.

                                                                                 Ron

Sent: Thursday, May 28, 2020 7:46 AM

Hi Ron,

https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#section-4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22*section-4__;Iw!!NEt6yMaO-gk!WUUoiYhNiQq44bqITjU9p16KKdON00tbtfOIgQoDmKHLycmNLLtVobJe9BtxN6V1$>

Thanks,

Ketan

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

Sent: 25 May 2020 21:14

Ketan,

                                                                 Ron

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

Hi Ron,

Thanks,

Ketan

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

Sent: 25 May 2020 09:03

Ketan,

        - Network programming

        - MPLS and uSID

                                                                           Ron

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

[SNIP]

[SNIP]

---

From: Ron Bonica <[email-masked]>
Date: Thu, 28 May 2020 16:55:47 +0000

Weibin,

Inline…..

                     Ron

Juniper Business Use Only
From: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>
Sent: Thursday, May 28, 2020 10:35 AM
To: Ketan Talaulikar (ketant) <[email-masked]>; Ron Bonica <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Ron,

[RB] Absolutely correct !!

[RB] In some deployment scenarios, the IPv6 FIB and the CRH-FIB are populated by an IGP. Please review and comment on the IS-IS CRH document<https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/>. I am excited to collaborate with you on that .

[RB] In other deployment scenarios, the IPv6 FIB and / or the CRH-FIB are populated by a controller. If you are interested in that scenario, again, we would be excited to collaborate with you.

                                                   Ron

Wang Weibin

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Ketan Talaulikar (ketant)
Sent: 2020年5月28日 19:46
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Hi Ron,

https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#section-4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22*section-4__;Iw!!NEt6yMaO-gk!VMgRZ_fS_8pBN886aeeU1sFZpteVAkwQNu6xqWRsR27VhEn_wpAuXmcCngHDrhN8$>

Thanks,

Ketan

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

Sent: 25 May 2020 21:14

Ketan,

                                                                 Ron

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

Hi Ron,

Thanks,

Ketan

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

Sent: 25 May 2020 09:03

Ketan,

        - Network programming

        - MPLS and uSID

                                                                           Ron

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

[SNIP]

[SNIP]

---

From: Peter Psenak <[email-masked]>
Date: Fri, 29 May 2020 11:11:00 +0200

Hi Ron,

On 28/05/2020 18:55, Ron Bonica wrote:
> *From:* Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>
> *Sent:* Thursday, May 28, 2020 10:35 AM
> *To:* Ketan Talaulikar (ketant) <[email-masked]>; Ron Bonica 
> <[email-masked]>; Joel M. Halpern <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; 6man <[email-masked]>
> *Subject:* RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of 
> CR in CRH
> 
> *[External Email. Be cautious of content]*
> 
> Hi Ron,
> 
> After reading through many mails related to CRH in list, I found all 
> CRH-SIDs (allocated to prefix-sid <loosely forwarding>and Adj-sid<strict 
> forwarding>) are of local significance in fact, its operation actually 
> is not same as MPLS Label nor SR-MPLS label (such as domain-wide prefix 
> SID/label), all CRH-SIDs are locally allocated by node itself based on 
> local FIB6, independent of other CRH-SID allocated by other nodes in CRH 
> domain; so every node (Maybe except  ingress PE of CRH domain)  has no 
> useful to learn other SIDs allocated by other nodes by IGP-extension 
> advertising. Its deployment must have controller (considering dynamic 
> mechanism), the controller learn all CRH-SIDs from each node to program 
> the source path under path calculation requirement from ingress PE.
> 

if CRH-SIDs are of local significance how is the loose source routing 
going to be supported?

Or is CRH only supposed to be used for strict hop-by-hop source routing? 
If so, the use case would be quite limited.

Honestly, strictly technically, I do not see much difference between CRH 
and RFC8663 & RFC4023 combo. Former uses an extra extension header, the 
latter uses the next-header. Rest looks same.

thanks,
Peter

> 
> I suggested you should describe more detail about how to create CRH-SID 
> entry (in CRH-FIB) in this CRH draft, is it based on local FIB6, if it 
> is, how to do synchronization between CRH-FIB and FIB6?
> 
> [RB] In some deployment scenarios, the IPv6 FIB and the CRH-FIB are 
> populated by an IGP. Please review and comment on the IS-IS CRH document 
> <https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/>. I 
> am excited to collaborate with you on that .
> 
> [RB] In other deployment scenarios, the IPv6 FIB and / or the CRH-FIB 
> are populated by a controller. If you are interested in that scenario, 
> again, we would be excited to collaborate with you.
> 
>                                                     Ron
> 
> *From:*ipv6 <[email-masked] <mailto:[email-masked]>> *On 
> Behalf Of *Ketan Talaulikar (ketant)
> *Sent:* 2020年5月28日19:46
> *To:* Ron Bonica <rbonica=[email-masked] 
> <mailto:rbonica=[email-masked]>>; Joel M. Halpern 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 6man <[email-masked] <mailto:[email-masked]>>
> *Subject:* RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of 
> CR in CRH
> 
> Hi Ron,
> 
> (i.e. a reduced portion of Spring Architecture) that only supports 
> prefix and adjacency SIDs as indicated by the two "forwarding methods".
> 
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22*section-4__;Iw!!NEt6yMaO-gk!VMgRZ_fS_8pBN886aeeU1sFZpteVAkwQNu6xqWRsR27VhEn_wpAuXmcCngHDrhN8$>
> 
>     o  Forward the packet to the next-hop along the least-cost path to 
> *>>> Prefix SID*
> 
> From: Ron Bonica <rbonica=[email-masked] 
> <mailto:rbonica=[email-masked]>>
> 
> Sent: 25 May 2020 21:14
> 
> <mailto:[email-masked]>>; Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>>
> 
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 6man <[email-masked] <mailto:[email-masked]>>
> 
> It would be fair to say that these operators  "wish to deploy IPv6 
> Traffic Engineering".  Some of these operators don't care about SR. Some 
> are actively averse to SRv6. All they want is a Routing header.
> 
>                                                                   Ron
> 
> From: Ketan Talaulikar (ketant) <ketant=[email-masked] 
> <mailto:ketant=[email-masked]>>
> 
> To: Ron Bonica <[email-masked] <mailto:[email-masked]>>; Joel 
> M. Halpern <[email-masked] <mailto:[email-masked]>>
> 
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 6man <[email-masked] <mailto:[email-masked]>>
> 
> I note that you are not anymore saying "Are not interested in SR" like 
> you had mentioned before the WG adoption call : 
> Segment Routing (i.e. a reduced portion of Spring Architecture) that 
> only supports prefix and adjacency SIDs as indicated by the two 
> "forwarding methods" that are referred to in draft-bonica-6man-comp-rtg-hdr?
> 
> Thanks,
> 
> Ketan
> 
> From: Ron Bonica <rbonica=[email-masked] 
> <mailto:rbonica=[email-masked]>>
> 
> Sent: 25 May 2020 09:03
> 
> <mailto:[email-masked]>>; Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>>
> 
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 6man <[email-masked] <mailto:[email-masked]>>
> 
> From: ipv6 <[email-masked] <mailto:[email-masked]>> On 
> Behalf Of Ketan Talaulikar (ketant)
> 
> To: Joel M. Halpern <[email-masked] <mailto:[email-masked]>>
> 
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 6man <[email-masked] <mailto:[email-masked]>>
> 
> help us answer these questions like the scope of the SID, 32-bit or 
> 16-bit or something else and what the CRH-FIB is going to turn out like.
> 
> [SNIP]
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 29 May 2020 06:12:06 -0400

> latter uses the next-header. Rest looks same.

    Gyan> Peter - You mentioned a key point which is is a major difference.

I thank you for pointing out this critical point for everyone in both
 Spring WG & 6MAN WG -now one big happy family🙏😀

With RFC 8663 SR-MPLS over
IPV6 using RFC 4023 w/o GRE with IPv6 encap here is what the end result of
the packet looks like:

 SR-MPLS over IPv6 =  Next header encapsulation

   IPv6 |  SR-MPLS |. Customer payload

Operators wanting CRH don’t want the MPLS Layer 2 1/2 MPLS data plane
insertion into the packet mucking up the packet and want to stay clear of
MPLS since they want a clean and pure IPV6 packet that follows RFC 8200
IPV6 specification.

So the use case for RFC 8663 is very different as it is widely deployed for
interworking SR-MPLS with SRV6 - Outlined in Mirsky draft below:

CRH is no different then using any other routing header proposal such as
6lo for RPL.

CRH Packet format:

IPV6  CRH | Customer payload

The additional encapsulation makes a big difference and it’s really apples
versus oranges and not the same at all.

  Why would any operator use SR-MPLS over IP to for steering traffic if
they have an existing IPV6 data plane they want to utilize.

They would use SRv6 or CRH and would pick CRH to avoid MSD (maximum sid
depth) issues for long strict paths and not have to deal with extra
complexity of all the compression variants.

Decision tree:
If an operator wanted an MPLS data plane variant they would go with SR-MPLS
but if they want IPV6 data plane variant they obviously would pick an
option that uses IPv6 data plane and that would be the SRV6 or CRH.

In order to even remotely justify from my point of view that SR-MPLS over
IPv6 would used for anything other than the obvious “interworking” between
SR-MPLS and SRV6, you would really have to prove that an operator is
willing to add MPLS into the mix when they want IPV6.  Not possible.

I can guarantee no operator would do that.

> > <
> https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22*section-4__;Iw!!NEt6yMaO-gk!VMgRZ_fS_8pBN886aeeU1sFZpteVAkwQNu6xqWRsR27VhEn_wpAuXmcCngHDrhN8$
> >
> >
> > <
> https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$
> >
> >
-- 

*Gyan Mishra*

---

From: Peter Psenak <[email-masked]>
Date: Fri, 29 May 2020 12:24:48 +0200

On 29/05/2020 12:12, Gyan Mishra wrote:
> 
> 
> On Fri, May 29, 2020 at 5:11 AM Peter Psenak 
> <ppsenak=[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Hi Ron,
> 
>      > *From:* Wang, Weibin (NSB - CN/Shanghai)
>     <[email-masked] <mailto:[email-masked]>>
>      > *To:* Ketan Talaulikar (ketant) <[email-masked]
>     <mailto:[email-masked]>>; Ron Bonica
>      > <[email-masked] <mailto:[email-masked]>>; Joel M.
>     Halpern <[email-masked] <mailto:[email-masked]>>
> IPV6 using RFC 4023 w/o GRE with IPv6 encap here is what the end result 
> of the packet looks like:
> 
> insertion into the packet mucking up the packet and want to stay clear 
> of MPLS since they want a clean and pure IPV6 packet that follows RFC 
> 8200 IPV6 specification.

you don't want MPLS, so you wrap the same data to a new extension header 
and give it a new name. And you suddenly like it. Hmm, does not sound 
like a solid technical argument to me.

thanks,
Peter

> 
> So the use case for RFC 8663 is very different as it is widely deployed 
> for interworking SR-MPLS with SRV6 - Outlined in Mirsky draft below:
> 
> The additional encapsulation makes a big difference and it’s really 
> apples versus oranges and not the same at all.
> 
> 
> If an operator wanted an MPLS data plane variant they would go with 
> SR-MPLS but if they want IPV6 data plane variant they obviously would 
> pick an option that uses IPv6 data plane and that would be the SRV6 or CRH.
> 
> In order to even remotely justify from my point of view that SR-MPLS 
> over IPv6 would used for anything other than the obvious “interworking” 
> between SR-MPLS and SRV6, you would really have to prove that an 
> operator is willing to add MPLS into the mix when they want IPV6.  Not 
> possible.
> 
>      > *From:*ipv6 <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> *On
>     <mailto:[email-masked]>
>      > <mailto:rbonica <mailto:rbonica>=[email-masked]
>     <mailto:[email-masked]>>>; Joel M. Halpern
>      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      > *Cc:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>; 6man
>     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      > <mailto:rbonica <mailto:rbonica>=[email-masked]
>     <mailto:[email-masked]>>>
>      >
>      > Sent: 25 May 2020 21:14
>      >
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>>; Joel M.
>     Halpern <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>>
>      >
>      > Cc: rtg-ads@ietf..org <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>; 6man
>     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >
>      > Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re:
>     Size of
>      > CR in CRH
>      >
>      > Ketan,
>      >
>     <ketant=[email-masked] <mailto:[email-masked]>
>      > <mailto:ketant <mailto:ketant>=[email-masked]
>     <mailto:[email-masked]>>>
>      >
>      > To: Ron Bonica <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; Joel
>      > M. Halpern <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >
>      > Cc: rtg-ads@ietf..org <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>; 6man
>     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >
>      > Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re:
>     Size of
>      > CR in CRH
>      >
>     <mailto:[email-masked]>
>      > <mailto:rbonica <mailto:rbonica>=[email-masked]
>     <mailto:[email-masked]>>>
>      >
>      > Sent: 25 May 2020 09:03
>      >
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>>; Joel M.
>     Halpern <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>>
>      >
>      > Cc: rtg-ads@ietf..org <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>; 6man
>     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >
>      > Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re:
>     Size of
>      > CR in CRH
>      >
>      > Ketan,
>      >
>      > From: ipv6 <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> On
>      > To: Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >
>      > Cc: rtg-ads@ietf..org <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>; 6man
>     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >
>      > Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re:
>     Size of
>      > CR in CRH
>      >
>      > [SNIP]
>      >
>     [email-masked] <mailto:[email-masked]>
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 29 May 2020 10:28:24 +0000

On 29/05/2020, 12:25, "ipv6 on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:

Wh> well said. On top we end up with reinventing the wheel and redoing what is already done.

    thanks,
    Peter

---

From: John Scudder <[email-masked]>
Date: Fri, 29 May 2020 14:12:31 +0000

[long list of individual email addresses trimmed from cc, mailing lists left]

Peter,

On May 29, 2020, at 5:11 AM, Peter Psenak <ppsenak=[email-masked]<mailto:ppsenak=[email-masked]>> wrote:

By having the locally-significant CRH identifier (I’ve lost track of the nom du jour :-) map in the CRH-FIB to a remote address (“segment endpoint”), toward which the packet is forwarded along the least-cost path. This is explicit in section 4:

Regards,

—John

---

From: Peter Psenak <[email-masked]>
Date: Fri, 29 May 2020 16:28:13 +0200

John,

On 29/05/2020 16:12, John Scudder wrote:
>> On May 29, 2020, at 5:11 AM, Peter Psenak 
>> <ppsenak=[email-masked] 
>> <mailto:ppsenak=[email-masked]>> wrote:
>>
> By having the locally-significant CRH identifier (I’ve lost track of the 
> nom du jour :-) map in the CRH-FIB to a remote address (“segment 
> endpoint”), toward which the packet is forwarded along the least-cost 
> path. This is explicit in section 4:
> 

how do nodes in the network learn about the local CRH identifier a node 
X allocated for a prefix residing on node Y?

thanks,
Peter

---

From: John Scudder <[email-masked]>
Date: Fri, 29 May 2020 14:33:00 +0000

On May 29, 2020, at 10:28 AM, Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:

This is also answered in section 4, AFAICT:

   The CRH-FIB can be populated:

   o  By an operator, using a Command Line Interface (CLI).

   o  By a controller, using the Path Computation Element (PCE)
      Communication Protocol (PCEP) [RFC5440<https://tools.ietf.org/html/rfc5440>] or the Network
      Configuration Protocol (NETCONF) [RFC6241<https://tools.ietf.org/html/rfc6241>].

   o  By a distributed routing protocol [ISO10589-Second-Edition<https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#ref-ISO10589-Second-Edition>],
      [RFC5340<https://tools.ietf.org/html/rfc5340>], [RFC4271<https://tools.ietf.org/html/rfc4271>].

I imagine the list isn’t meant to be exhaustive, some other minor variations have been discussed on-list IIRC.

—John

---

From: Peter Psenak <[email-masked]>
Date: Fri, 29 May 2020 16:36:49 +0200

John,

On 29/05/2020 16:33, John Scudder wrote:
>        Communication Protocol (PCEP) [RFC5440  <https://tools.ietf.org/html/rfc5440>] or the Network
>        Configuration Protocol (NETCONF) [RFC6241  <https://tools.ietf.org/html/rfc6241>].
> 
>     o  By a distributed routing protocol [ISO10589-Second-Edition  <https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#ref-ISO10589-Second-Edition>],
>        [RFC5340  <https://tools.ietf.org/html/rfc5340>], [RFC4271  <https://tools.ietf.org/html/rfc4271>].

well, advertising the local CRH identifier for every node and adjacency 
in the network from every other node is clearly a no-go from the IGP 
perspective.

Not to mention that the proposed encoding in 
draft-bonica-lsr-crh-isis-extensions only allows one to advertise the 
CRH identifier for a local prefix and adjacency, not for the remote ones.

thanks,
Peter

> 
> 
> I imagine the list isn’t meant to be exhaustive, some other minor 
> variations have been discussed on-list IIRC.
> 
> —John

---

From: John Scudder <[email-masked]>
Date: Fri, 29 May 2020 14:56:04 +0000

Peter,

On May 29, 2020, at 10:36 AM, Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:

(Of course this objection only applies to the final (“distributed routing protocol”) bullet point.)

We’re recapitulating conversation that has been done on-list at least once. If I had time I’d find the reference and post, but as we know the conversation is hundreds of messages deep (at least!) and I don’t; sorry. Maybe someone else has a reference handy? If I recall correctly (and I may not) one exemplary solution to your objection is to make use of globally-unique (per domain, of course) identifiers, and yes, I do mean something semantically similar to a SR Node-SID. Other solutions are possible, depending on the use case — if the use case doesn’t require any-to-any connectivity within the domain, you potentially don’t need O(N^2) CRH identifiers to be present in the LS(P)DB even absent any kind of global uniqueness. Granted that any-to-any is the most general case.

That seems out of scope for discussion of CRH per se, unless you mean to say “this problem cannot be solved” instead of “this particular solution is deficient”. If it’s the latter, I think the LSR mailing list seems like a better place to take it up with the authors of draft-bonica-lsr-crh-isis-extensions.

—John

---

From: Peter Psenak <[email-masked]>
Date: Fri, 29 May 2020 17:14:00 +0200

John,

> routing protocol”) bullet point.)

correct.

> 
> We’re recapitulating conversation that has been done on-list at least 
> once. If I had time I’d find the reference and post, but as we know the 
> conversation is hundreds of messages deep (at least!) and I don’t; 

no worries, below summary is sufficient.

> sorry. Maybe someone else has a reference handy? If I recall correctly 
> (and I may not) one exemplary solution to your objection is to make use 
> of globally-unique (per domain, of course) identifiers, and yes, I do 
> mean something semantically similar to a SR Node-SID. Other solutions 
> are possible, depending on the use case — if the use case doesn’t 
> require any-to-any connectivity within the domain, you potentially don’t 
> need O(N^2) CRH identifiers to be present in the LS(P)DB even absent any 
> kind of global uniqueness. Granted that any-to-any is the most general case.

so if we design for a most general case, it's obvious that the locally 
unique CRH identifiers are problematic, at least when distributed 
routing protocol is being used to populate CRH-FIB.

>> draft-bonica-lsr-crh-isis-extensions only allows one to advertise thener
> That seems out of scope for discussion of CRH per se, unless you mean to 
> say “this problem cannot be solved” instead of “this particular solution 
> is deficient”. If it’s the latter, I think the LSR mailing list seems 
> like a better place to take it up with the authors 
> of draft-bonica-lsr-crh-isis-extensions.

sure, just tried to connect things together, but let's ignore it for a 
time being.

thanks,
Peter

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 29 May 2020 09:42:02 -0700

I can beat that ;-) AFAIR, my first job in IBM in the 80s was to remove
loose source routing code from token ring bridges since it was causing
operationally too many problems ...

-- tony

On Thu, May 28, 2020 at 8:13 AM Ron Bonica <rbonica=
[email-masked]> wrote:

> Ketan,
>
>
>
> Neither of these forwarding methods are unique to SR.. In Section 3.1 of
> RFC 791, you will see that IPv4 had a Strict Source Route Option and a
> Loose Source Route Option. These predate SR by roughly twenty-five years.
>
>
>
>
> Ron
>
>
>
>
>
> *From:* Ketan Talaulikar (ketant) <ketant=[email-masked]>
> *Sent:* Thursday, May 28, 2020 7:46 AM
> *To:* Ron Bonica <[email-masked]>; Joel M. Halpern <
> [email-masked]>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22*section-4__;Iw!!NEt6yMaO-gk!WUUoiYhNiQq44bqITjU9p16KKdON00tbtfOIgQoDmKHLycmNLLtVobJe9BtxN6V1$>
>
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 29 May 2020 16:48:04 +0000

Hi Gyan,

Thanks again for sharing your perspective and I believe the points you make would certainly contribute in the analysis of different SR mechanisms and their pros/cons. So I definitely see the value of the points that you make and they seem to set the context for the use-cases and requirements for SRm6. May I suggest that the SRm6 authors incorporate your inputs into their draft for review?

Sadly, with this WG adoption call for just the CRH draft, we seem to be bypassing all of those very important analysis and discussions of SRm6 in Spring.

Seems like the cart has been put before the horse in this case.

Thanks,
Ketan

From: Gyan Mishra <[email-masked]>
Sent: 28 May 2020 20:27
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: 6man <[email-masked]>; Joel M. Halpern <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

On Thu, May 28, 2020 at 7:46 AM Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc..ietf.org<mailto:[email-masked]>> wrote:

Hi Ron,

 Gyan> Ketan - you are misunderstanding the CRH architecture.  It uses the IPv6 data plane so is a variant of SRV6 and not SR-MPLS.

SR-MPLS reused then MPLS  data plane to create  fec bindings and uses label stacking for steering cSPF static lsp using the MPLS forwarding plane.
Operators that want CRH don’t want to go backwards and use SR-MPLS and have the baggage of MPLS data plane as in general these are green field operators use cases.

SR-MPLS he it’s place and where it shines and works well is for brown field operators with existing MPLS LDPv4 deployments it’s a simple migration to SR-MPLS.

For operators that already have an IPV6 core  or are running MPLS LDPv6 brown field deployments,  then then SRV6 or now CRH or SRM6 are the viable options.

    CRH introduces a new RH similar to RH0 or any of      the other new RH introduces for simple source routing which has been around since IPv4.

CRH does not use the segments in the RH  to build the actual static hop by hop steered path as does SR-MPLS via SRGB block label stacking.

     Remember CRH is just another IPV6 Routing header.  However now instead of copying the routing  segment into the segment list to the IPv6 destination address as done with SRV6 their is one simple extra step.  A CRH-FIB entry is created manually that is referenced by the routing segment and that entry is the IPv6 address that is copied to the next hop destination address to steer the packet hop by hop.

By not storing the IPV6 address in the CRH RH you save all the problem with MSD(Maximum SID depth) issues that occur in with SRv6 which really makes SRV6 not viable for long strict SR-TE paths using adjacency sid that are more then a few hops due to MSD issue.  SRV6 has its complex programming with end prefix sid and end.x adjacency sid instantiations overhead that makes SRV6 not viable for operators that don’t want to add in all the additional complexity of the many compression drafts 6+ that exist today to resolve the MSD issue.

Speaking from an operator perspective, representing Verizon a Tier 1 carrier, we have use cases as other carriers for intra domain very very long static per VRF coloring of L3 vpn instantiated strict paths using SR-TE and flexalgo.  However SRv6 by itself does not stack up and requires use of the compression techniques for SR-TE per VRF coloring.

Unfortunately for SRV6 it failed to start out of the gate natively and could not deliver on per VRF coloring of long strict paths using SR-TE binding SID which is what the industry has been clamoring for.

The major benefit for CRH is that natively it can have very very long strict hop by hop steered paths without requiring additional complexity component for compression techniques to make it work as does SRV6.

SRv6 has its place in the industry and works well with  short cSPF paths using prefix sid and staying away from hop by hop long strict explicit paths.  And if you are willing to add the complexity of one of the many compression techniques then so be it and that makes SRV6 viable as well as an option for operators requiring long strict paths.

For Verizon we would use SRM6 as it is the full blown version of CRH as it has the IGP extensions and supports SR-TE binding sid.

For the many use cases where a very long strict hop by hop path is required and you want to use your existing IPv6 data plane, then CRH is the answer as it is a low overhead means of source routing and works plug-n-play out of the box using the IPv6 data plane.  No need for any of the many compression techniques as required by SRv6 for building strict paths.

The comments related to SR-MPLS over IPv6 RFC 8663 using tunneling techniques RFC 4023 MPLS over GRE in IPinIP w/o GRE using IPv6 outer header similar to Universal SID draft used for SRV6 to SR-MPLS interworking.  There are use case for using RFC 8663 but that in my mind would be for Mirsky Universal SID interoperability use cases where you require interworking between SR-MPLS and SRv6 the tunneling of SR-MPLS in outer IPV6 header with RFC 8663.

This is completely different from CRH..  If you need interworking you use RFC 8663 with Mirsky draft or if you need a very simple low overhead technique for source routing capability that works right out of the box then CRH is the answer.

Kind Regards

Ketan

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

Sent: 25 May 2020 21:14

Ketan,

It would be fair to say that these operators  "wish to deploy IPv6 Traffic Engineering"..  Some of these operators don't care about SR. Some are actively averse to SRv6. All they want is a Routing header.

                                                                 Ron

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

Hi Ron,

Thanks,

Ketan

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

Sent: 25 May 2020 09:03

Ketan,

        - Network programming

        - MPLS and uSID

                                                                           Ron

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

[SNIP]

[SNIP]

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 29 May 2020 16:54:21 +0000

Hi Ron,

You are correct and I don't believe I said that the Segment Routing (Spring) work has a special claim on them. My point was that it is a subset of what is covered by Spring architecture.

The more important point was that with the use of mapping IDs and mapping FIB, the proposal is comparable more to SR-MPLS than SRv6. It is better to do a holistic analysis of any proposal such as CRH that is introducing an MPLS label like mapping construct into IPv6 architecture - doing so should be considered as a significant change to IPv6.

Thanks,
Ketan

Sent: 28 May 2020 20:41

Ketan,

Neither of these forwarding methods are unique to SR.. In Section 3.1 of RFC 791, you will see that IPv4 had a Strict Source Route Option and a Loose Source Route Option. These predate SR by roughly twenty-five years.

                                                                                 Ron

Hi Ron,

Thanks,

Ketan

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

Sent: 25 May 2020 21:14

Ketan,

                                                                 Ron

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

Hi Ron,

Thanks,

Ketan

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

Sent: 25 May 2020 09:03

Ketan,

        - Network programming

        - MPLS and uSID

                                                                           Ron

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

[SNIP]

[SNIP]

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 29 May 2020 19:11:27 +0200

John,

Draft under the adoption call as well as its author sent 10s if not more
messages stating that CRH-SIDs are **locally significant*. *

Now after few discussions about scaling aspects of such design choice you
are suddenly stating:

*" one exemplary solution to your objection is to make use of
globally-unique (per domain, of course) identifiers"*

so at this point the main characteristics of the proposal seems at least
very elastic.

With that what exactly is the proposal 6man is subject to adopt if it is
fundamentally changing every day ?

Note that if IDs are globally domain wide significant then you suddenly
need to worry about ID space collision. Would next the index would be
introduced just like SR-MPLS addresses that problem ?

I remain with my opinion that current draft is not even stable enough for
adoption in any WG.

Regards,
Robert.

On Fri, May 29, 2020 at 4:56 PM John Scudder <jgs=
[email-masked]> wrote:

> Peter,
>
> On May 29, 2020, at 10:36 AM, Peter Psenak <[email-masked]> wrote:
>
> conversation is hundreds of messages deep (at least!) and I don’t; sorry.
> Maybe someone else has a reference handy? If I recall correctly (and I may
> not) one exemplary solution to your objection is to make use of
> globally-unique (per domain, of course) identifiers, and yes, I do mean
> something semantically similar to a SR Node-SID. Other solutions are
> possible, depending on the use case — if the use case doesn’t require
> any-to-any connectivity within the domain, you potentially don’t need
> O(N^2) CRH identifiers to be present in the LS(P)DB even absent any kind of
> global uniqueness. Granted that any-to-any is the most general case.
>
> say “this problem cannot be solved” instead of “this particular solution is
> deficient”. If it’s the latter, I think the LSR mailing list seems like a
> better place to take it up with the authors