Subject: CRH and RH0

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 12 May 2020 18:26:35 +0000

Hi Ron,

You mentioned in the 6man meeting that:
1 - CRH is not intended to be a replacement for RH0
2 - CRH is not intended for use on the internet (i.e. only within a domain).

Will you be updating draft-bonica-6man-comp-rtg-hdr to reflect that?

Thanks
  Darren

---

From: Ron Bonica <[email-masked]>
Date: Tue, 12 May 2020 18:32:27 +0000

Hi Darren,

The second issue is already addressed in the Security Consideration section.

I would be glad to add a sentence saying that CRH is not a replacement for RH0, but I am not sure what value that sentence will have to someone who will read the document in 25 years. Could you help me understand the benefit? Why would the reader care?

                                                                            Ron

Juniper Business Use Only

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]> 
Sent: Tuesday, May 12, 2020 2:27 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: CRH and RH0

[External Email. Be cautious of content]

Hi Ron,

Thanks
  Darren

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 12 May 2020 18:54:15 +0000

Hi Ron,

The introduction spends its time likening CRH to RH0 and says it differs by “encoded in fewer bytes” and “addresses security vulnerabilities”

I was left with the impression that you are attempting to recreate another general use IPv6 routing header for the internet.  Like RH0.

It's only in section 9 where there is a hint that is not the case, you say “Networks that process the CRH MUST…”.  I could not find a definition of these networks.

Darren

> On May 12, 2020, at 2:32 PM, Ron Bonica <[email-masked]> wrote:
> 
> Hi Darren,
>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 12 May 2020 12:13:09 -0700

Darren,

The way RH0 was deprecated in RFC5095, specifically the rules on how a router should treat receiving an RH0 option, I think it is clear this is not a replacement for RH0 (as in reusing the routing header type).   To me, it clearly proposing a new Routing Header, and as such it does have to deal with the issues that caused RH0 to be deprecated.

I note that values 5-252 are Unassigned, so we can support a few more :-)

Bob

> On May 12, 2020, at 11:54 AM, Darren Dukes (ddukes) <ddukes=[email-masked]> wrote:
> 
> Hi Ron,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Tue, 12 May 2020 20:13:12 +0000

Hi Darren,

The answer to your question is a bit nuanced. My goals were to build a general purpose routing header that overcomes the RH0's limitations. Those being:

	- Its size
	- Its security issues

Now, is that a replacement for RH0? In one way, yes. RH0 and CRH are both general purpose routing headers. In another sense, no. RH0 is meant to traverse network boundaries. But RFC 5095 taught us that letting routing header traverse network boundaries might not be a wonderful idea. So, CRH is restricted to a network domain.

And now I return to my original question. When engineering students read the CRH RFC in 25 years, will they really care what my motivation was? Why should we burden them with this detail?

                                                                                                     Ron

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]> 
Sent: Tuesday, May 12, 2020 2:54 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: CRH and RH0

Hi Ron,

Darren

---

From: [email-masked]
Date: Tue, 12 May 2020 22:38:26 +0200

Hi Ron,

> Now, is that a replacement for RH0? In one way, yes. RH0 and CRH are both general purpose routing headers. In another sense, no. RH0 is meant to traverse network boundaries. But RFC 5095 taught us…

If CRH could be a RH0 replacement, you would have to show how the tag distribution mechanism would work across the Internet?
RH0 was supported in every IPv6 node, given the requirement for a tag->IPv6 address (or is it forwarding method) mapping, I can't quite see how that would be done in a general enough fashion for CRH?

I don't think RFC5095 taught us that source routing cannot be done across the Internet.
In fact I don't see how the CRH draft prevents the RFC5095 attack to happen inside of the CRH limited domain.
Just send a packet with a list of tag#0, tag#1, tag#0, tag#1 and you have the same amplification attack.

> And now I return to my original question. When engineering students read the CRH RFC in 25 years, will they really care what my motivation was? Why should we burden them with this detail?

To the contrary. Take the motivations and intentions behind IPv6. We have spent thousands of emails trying to decode what the original intensions with EHs and their limitations were, why the minimum MTU was 1280, recently I saw a thread about the reasons for why TTL/HL and protocol/next header was swapped between v4 and v6. If your protocol is successful, the original napkin it was designed on will become legend. ;-)

Best regards,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Tue, 12 May 2020 21:36:19 +0000

Ole, Darren,

The CRH is a general purpose Routing header that operates inside of a network domain. In the sense that it is a general purpose routing header, it replaces RH0. In the sense that it is restricted to a network domain, it does not replace RH0.

If adding these two sentences will cause you to support the draft, or at least not object to it, I will happily add them!

Are these the only objections?

                                                                                    Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, May 12, 2020 4:38 PM
To: Ron Bonica <[email-masked]>
Cc: Darren Dukes (ddukes) <[email-masked]>; 6man <[email-masked]>
Subject: Re: CRH and RH0

Hi Ron,

Best regards,
Ole

---

From: [email-masked]
Date: Tue, 12 May 2020 23:47:27 +0200

Hi Ron,

> Are these the only objections?

I wasn't intending to object or to support.
I wanted to explore the claim that this could be a RH0 replacement.

I don't think you have substantiated how it possibly could be that.
It might be a digression from what you are trying to do here, so I'm fine with leaving it at that.

Cheers,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Tue, 12 May 2020 21:54:42 +0000

Ole,

What claim needs further substantiation?

                         Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, May 12, 2020 5:47 PM
To: Ron Bonica <[email-masked]>
Cc: Darren Dukes (ddukes) <[email-masked]>; 6man <[email-masked]>
Subject: Re: CRH and RH0

Hi Ron,

Cheers,
Ole

---

From: [email-masked]
Date: Wed, 13 May 2020 00:04:00 +0200

Ron,

> What claim needs further substantiation?

Eh... the claim that CRH could be a RH0 replacement.
Not sure if that's something we'd want anyway, but I wasn't the one making that claim.
Nor did I think that was CRH's purpose.

To repeat:

Ole

---

From: Ron Bonica <[email-masked]>
Date: Tue, 12 May 2020 22:23:13 +0000

Ole,

The draft never claimed to be a replacement for RH0. It only claimed to address RH0's shortcomings.

                                                                                         Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, May 12, 2020 6:04 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: CRH and RH0

Ron,

To repeat:

Ole

---

From: Bob Hinden <[email-masked]>
Date: Tue, 12 May 2020 15:58:19 -0700

Ron,

> On May 12, 2020, at 3:23 PM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Ole,
> 

Any new RH needs to show why it doesn’t have the problems that RH0 did.   That does not make it a replacement for RH0, just a new Routing header.

In my view, anything claiming to be a replacement for RH0 would need to have full IPv6 addresses.   That doesn’t appear to be the case with what you are proposing.

Bob

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 00:35:56 +0000

Bob,

I agree. 

But now I have to ask what the objections to progressing this draft might be? Does it damage the Internet? Does it violate some other RFC? Does it consume some scarce resource?

Given that it is only fifteen pages long, I suspect that progressing it would be less work than arguing about whether to progress it.

                                                   Ron

-----Original Message-----
From: Bob Hinden <[email-masked]> 
Sent: Tuesday, May 12, 2020 6:58 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Ole Trøan <[email-masked]>; 6man <[email-masked]>
Subject: Re: CRH and RH0

Ron,

Bob

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Wed, 13 May 2020 02:00:03 +0000

Hi Ron,

<I copied the SPRING mailing list since some of my comments are also related with the SPRING WG. Hope it is ok.>

I have short experience in IETF compared with most of you with decades of experience, but still I believe that people do care about the motivations as well as the students in 25 years. From my observation and understanding, in IETF even to bring a small extension to the existing protocol the community will require proper justifications. People will ask why we need this extension, and why the existing solutions cannot solve the same issue. Don’t need to mention about the justifications that would be required for a general purpose routing header as you call it.

There have been a few RHs already defined in IETF. For the one that I have experienced part of its standardization process, i.e. SRH, I have learned that there is an architecture (RFC8402) draft defined for it as well as related problem statement (RFC7855) and use cases (RFC8354, RFC8355) drafts in SPRING. There are so many other drafts active in SPRING and other working groups built upon the SRH in almost every aspect, which in the meantime also justify its value.

For CRH, the IPv6 Compressed Routing Header (CRH), from the title wise, I don’t see why it should be called a general purpose routing header. Its use to me is pretty clear, that is for compression. Can we say compression is the use case of this routing header? Is there any other use cases for it? If we call it a general purpose, it would be better if it can be used in general case or to cover more general use cases.

Regarding the justification of CRH, I did notice that in its version 10 there was a normative reference to a SPRING draft [I-D.bonica-spring-srv6-plus], but it was removed from version 11. I am not quite sure about your motivation to have this action. But I have been taken SRv6+ now SRm6 as the architecture and justification of CRH. Probably some people also had the same feeling.

If compression is the use case and SRm6 is the justification, currently there have already been a few solutions on the table of SPRING. People are working together to evaluate those solutions to solve the size issue, the same as one of the purpose of CRH. So would it be better for CRH to join the discussion there and solve the lengthy header issue altogether? That would mean a lot to the community for now.

My two cents.

Thank you!

Best regards, 
Shuping 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Wednesday, May 13, 2020 4:13 AM
To: Darren Dukes (ddukes) <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: CRH and RH0

Hi Darren,

	- Its size
	- Its security issues

                                                                                                     Ron

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]> 
Sent: Tuesday, May 12, 2020 2:54 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: CRH and RH0

Hi Ron,

Darren

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 May 2020 19:28:52 -0700

Ron,

Not to nit-pick, but doesn't CRH require a specific control plane to
be useful which would make it less than general purpose? I don't
believe RH0 had such a requirement. Also there's the RH in RFC6554
that has a similar goal in compressing the addresses in the routing
header, but doesn't seem to require additional control plane logic
either. I think these might be worth referencing.

Tom
.
> Are these the only objections?

It would seem the goals of CRH are very similar to RFC6554 in
compressing the addresses in the routing header. I think this might be
worth referencing.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 May 2020 09:22:29 +0200

Hi Ron,

> Given that it is only fifteen pages long, I suspect that progressing it
> would be less work than arguing about whether to progress it.

Sometimes committing a bit more work yields much better results in the long
run ...

So it is clear that you are not just trying to fix suboptimalities of IPv6
encoding out of the woods. The goal is clear to get this in and use it as a
hook to show in SPRING and other routing WGs in IETF that since you have
CRH accepted as a WG docs in 6man other groups should follow along and work
on SRm6 encodings.

The mapping plane between SIDs and labels is already in place in SR-MPLS.
Just changing few bit here and there does not make new proposal to stand on
its own.

I think it has been clearly stated by 6man chairs and AD that any work on
SRm6 can be taken on only after SPRING WG accepts the main concept and
adopts the main doc as a WG item.

So I recommend we go via this proper path with the full picture in mind and
the ultimate objective for CRH.

Best regards,
R.

---

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

Robert,

At the interim meeting, I said that there are IPv6 operators who:

  *   Want CRH
  *   Are not interested in SR
  *   Are averse to SRv6

Are you questioning whether that statement is true?

                                                          Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Wednesday, May 13, 2020 3:22 AM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; 6man <[email-masked]>
Subject: Re: CRH and RH0

Hi Ron,

Sometimes committing a bit more work yields much better results in the long run ...

So it is clear that you are not just trying to fix suboptimalities of IPv6 encoding out of the woods. The goal is clear to get this in and use it as a hook to show in SPRING and other routing WGs in IETF that since you have CRH accepted as a WG docs in 6man other groups should follow along and work on SRm6 encodings.

The mapping plane between SIDs and labels is already in place in SR-MPLS. Just changing few bit here and there does not make new proposal to stand on its own.

I think it has been clearly stated by 6man chairs and AD that any work on SRm6 can be taken on only after SPRING WG accepts the main concept and adopts the main doc as a WG item.

So I recommend we go via this proper path with the full picture in mind and the ultimate objective for CRH.

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 May 2020 17:22:13 +0200

Hi Ron,

>  Are you questioning whether that statement is true?

Yes. Especially this point: " Are not interested in SR"

Your draft only talks about SIDs and segments so no matter how you call it
the core purpose is segment routing.

Take care,
R.

On Wed, May 13, 2020 at 5:13 PM Ron Bonica <[email-masked]> wrote:

>    - Want CRH
>    - Are not interested in SR
>    - Are averse to SRv6
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, May 13, 2020 3:22 AM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* Bob Hinden <[email-masked]>; 6man <[email-masked]>
> *Subject:* Re: CRH and RH0
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Ron,
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 15:35:49 +0000

Tom,

CRH is unique in that it requires a CRH-FIB. However, it doesn't require an special control plane support. The CRH-FIB can be created:

- by configuration (CLI)
- by a controller 
- by a IGP

I would still argue that CRH is a "general purpose" solution because:

- It is applicable in a wide variety of use-cases
- It doesn't rely on anything other than IPv6 cannon (e.g., RFC 8200, RFC 4291) and what is specified in the CRH draft.

It's just another tool in the IPv6 tool box.

                                                                                                         Ron

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Tuesday, May 12, 2020 10:29 PM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: Re: CRH and RH0

Ron,

Not to nit-pick, but doesn't CRH require a specific control plane to be useful which would make it less than general purpose? I don't believe RH0 had such a requirement. Also there's the RH in RFC6554 that has a similar goal in compressing the addresses in the routing header, but doesn't seem to require additional control plane logic either. I think these might be worth referencing.

Tom
..
> Are these the only objections?

It would seem the goals of CRH are very similar to RFC6554 in compressing the addresses in the routing header. I think this might be worth referencing.
> To the contrary. Take the motivations and intentions behind IPv6. We 
> have spent thousands of emails trying to decode what the original 
> intensions with EHs and their limitations were, why the minimum MTU 
> was 1280, recently I saw a thread about the reasons for why TTL/HL and 
> protocol/next header was swapped between v4 and v6. If your protocol 
> is successful, the original napkin it was designed on will become 
> legend. ;-)
>
> Best regards,
> Ole
>
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!VCsmnDZrlJb72chjZsxpFTzE3HDirD3f2dZKrrUJjn1YVZWUhae_u
> jIzFjntGXzC$

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 15:39:32 +0000

Robert,

So, you are really sure that these people don't exist. Would you like to make a more explicit statement?

                                                                  Ron

Sent: Wednesday, May 13, 2020 11:22 AM

Hi Ron,

Your draft only talks about SIDs and segments so no matter how you call it the core purpose is segment routing.

Take care,
R.

On Wed, May 13, 2020 at 5:13 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

*         Want CRH

*         Are averse to SRv6

                                                          Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 13, 2020 3:22 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

Hi Ron,

Best regards,
R.

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 15:41:43 +0000

Robert,

Oh, btw. RH0 had a "Segments Left" field. Because it talked about segments, would you like to claim that it was also SR?

                                                                           Ron

Juniper Business Use Only
From: Ron Bonica
Sent: Wednesday, May 13, 2020 11:40 AM
To: Robert Raszuk <[email-masked]>
Cc: Bob Hinden <[email-masked]>; 6man <[email-masked]>
Subject: RE: CRH and RH0

Robert,

                                                                  Ron

Hi Ron,

Take care,
R.

*         Want CRH

*         Are averse to SRv6

                                                          Ron

Hi Ron,

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 May 2020 17:43:23 +0200

Hi Ron,

It is not about existence of people.

It is about what the draft proposes vs what segment routing is in general.

You stating that people are not interested in SR but yet want segment
endpoint encoding as described in the draft is very confusing at best,

Many thx,
R,

On Wed, May 13, 2020 at 5:39 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> So, you are really sure that these people don’t exist. Would you like to
> make a more explicit statement?
>
>
>
>                                                                   Ron
>
>
>
>
>
> *Sent:* Wednesday, May 13, 2020 11:22 AM
> ·         Want CRH
> ·         Are not interested in SR
>
> ·         Are averse to SRv6
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 15:52:21 +0000

Robert,

I am glad to hear that you are not calling me a liar. Now, let's continue the conversation.

It sounds like you are saying that the 6man WG cannot standardize some class of Routing headers without permission from the SPRING WG. Can you draw a clear boundary around that class of Routing headers?

                                                                           Ron

Sent: Wednesday, May 13, 2020 11:43 AM

Hi Ron,

You stating that people are not interested in SR but yet want segment endpoint encoding as described in the draft is very confusing at best,

Many thx,
R,

On Wed, May 13, 2020 at 5:39 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                  Ron

Hi Ron,

Take care,
R.

*         Want CRH

*         Are averse to SRv6

                                                          Ron

Hi Ron,

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 May 2020 17:55:23 +0200

Ron,

Oh - haven't we established just yesterday that you will not be referencing
RH0 any longer with CRH proposal  ?

It's like you are trying to build a vehicle  .. it has wheels, steering and
even seats (no engine and no belts for now). But you keep insisting - it is
not a car.

See if you put *normative reference* to segment routing up to version -10
then suddenly drop it with no major change to the body of the draft the
intentions are just obvious:

13 <https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10#section-13>.
References
13.1 <https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10#section-13.1>.
Normative References

   [I-D.bonica-spring-srv6-plus]
              Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques,
              D., Jalil, L., Halpern, J., Linkova, J., and G. Chen,
              "Segment Routing Mapped To IPv6 (SRm6)", draft-bonica-
<https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-06>

spring-srv6-plus-06
<https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-06> (work in
progress), October 2019.

REF: https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10

On Wed, May 13, 2020 at 5:41 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> Oh, btw. RH0 had a “Segments Left” field. Because it talked about
> segments, would you like to claim that it was also SR?
>
>
>
>
> Ron
>
>
>
>
>
> *From:* Ron Bonica
> *Sent:* Wednesday, May 13, 2020 11:40 AM
> *To:* Robert Raszuk <[email-masked]>
> *Subject:* RE: CRH and RH0
>
>
>
> Robert,
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 16:11:19 +0000

Robert,

                                                                  Ron

Sent: Wednesday, May 13, 2020 11:55 AM

Ron,

Oh - haven't we established just yesterday that you will not be referencing RH0 any longer with CRH proposal  ?

It's like you are trying to build a vehicle  .. it has wheels, steering and even seats (no engine and no belts for now). But you keep insisting - it is not a car.

See if you put normative reference to segment routing up to version -10 then suddenly drop it with no major change to the body of the draft the intentions are just obvious:

13<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10*section-13__;Iw!!NEt6yMaO-gk!SOeabesZ6XuhCEeNa9hXekEBH6ofETz6Yw06-TRbVHaMbjj1LXax5iTjyB3RRAb-$>.  References

13.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10*section-13.1__;Iw!!NEt6yMaO-gk!SOeabesZ6XuhCEeNa9hXekEBH6ofETz6Yw06-TRbVHaMbjj1LXax5iTjyMrjdK6g$>.  Normative References

              "Segment Routing Mapped To IPv6 (SRm6)", draft-bonica-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-srv6-plus-06__;!!NEt6yMaO-gk!SOeabesZ6XuhCEeNa9hXekEBH6ofETz6Yw06-TRbVHaMbjj1LXax5iTjyJ5ZtD0U$>
spring-srv6-plus-06<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-srv6-plus-06__;!!NEt6yMaO-gk!SOeabesZ6XuhCEeNa9hXekEBH6ofETz6Yw06-TRbVHaMbjj1LXax5iTjyJ5ZtD0U$> (work in progress), October 2019.

REF: https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10__;!!NEt6yMaO-gk!SOeabesZ6XuhCEeNa9hXekEBH6ofETz6Yw06-TRbVHaMbjj1LXax5iTjyPvF0qCu$>

On Wed, May 13, 2020 at 5:41 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                           Ron

Juniper Business Use Only
From: Ron Bonica
Sent: Wednesday, May 13, 2020 11:40 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: CRH and RH0

Robert,

                                                                  Ron

Hi Ron,

Take care,
R.

*         Want CRH

*         Are averse to SRv6

                                                          Ron

Hi Ron,

Best regards,
R.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 13 May 2020 17:12:03 +0100

> On 13 May 2020, at 16:55, Robert Raszuk <[email-masked]> wrote:
> 

Many non-car vehicles have those characteristics, bicycles and aeroplanes to name just two.

Stewart

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 May 2020 09:15:46 -0700

Gentlepeople,

IPv6 routing headers starting with RFC1883 published in 1995 used the term “segments” to identify elements in the list of addresses.   In that sense, all IPv6 routing headers do some form of segment routing.  It’s a generic term that has been around for 25 years.

I think the underlying question with CRH is does it conflict with what is being done in the Spring w.g.

To my thinking, what is being done in Spring is an architecture for distributing information that can be used to create source routes for SRH (RFC8754).   Anything that relies on that set of Spring routing protocols is part of the working being done in Spring.

Likewise, to my thinking I don’t think that means that all new IPv6 routing headers conflict with the work being done in the Spring w.g.

Bob

> On May 13, 2020, at 8:55 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Ron,
> 
> 13.  References
> 13.1.  Normative References
> 
> 
>    [
> I-D.bonica-spring-srv6-plus
> ]
> spring-srv6-plus-06 (work in progress), October 2019.
> 
> Oh, btw. RH0 had a “Segments Left” field. Because it talked about segments, would you like to claim that it was also SR?
> 
> 
> 
>                                                                            Ron
> 
> 
> 
> 
> 
> So, you are really sure that these people don’t exist. Would you like to make a more explicit statement?
> 
> 
> 
>                                                                   Ron
> 
> 
> 
> 
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 16:27:14 +0000

Bob,

I think that your analysis is absolutely correct. Anything that relies on SPRING routing protocols is SPRING.

I would add the corollary statement, anything that does not rely on SPRING routing protocols is not SPRING.

Therefore, if CRH can be deployed in the absence of any routing protocol at all  (i.e., with static routes and a statically configured CRH-FIB), it is not SPRING.

                                                                                                           Ron

-----Original Message-----
From: Bob Hinden <[email-masked]> 
Sent: Wednesday, May 13, 2020 12:16 PM
To: 6man <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>
Subject: Re: CRH and RH0

Gentlepeople,

Bob

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 May 2020 09:29:25 -0700

Ron

Each of those are examples of additional control plane functionality
that creates state that has to be disseminated through the network. In
contrast, if RFC6554 is used then the route list just expands to
simple IP addresses that can be routed using the normal FIB. If all
the user wants to do is route their packets through specific nodes in
the network then this seems like a perfectly good solution. If they
want to perform "network programming" then I suppose they might need
the additional complexity of SIDs.

> It's just another tool in the IPv6 tool box.

I agree it's another tool in the tool box and it's a clean model, but
I still wish there was a mode where it could just work "out of the
box".

Tom

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 May 2020 19:08:53 +0200

Ron,

> I would add the corollary statement, anything that does not rely on SPRING routing protocols is not SPRING.

That seems at first glance to be too simplistic. At least something we need to explore further. 

RH0 requires no control plane or coordination between nodes. 
SRH and CRH both require a coordinated control plane. In the CRH case the tag to forwarding method and I guess similarly SID to forwarding instruction for SRH. 
How you distribute this information doesn’t seem to be the distinguishing factor. Both SRH and CRH could surely use cli, netconf or a routing protocol, right?

What in my mind distinguishes RH0 from CRH/SRH is also the concept of forwarding method. RH0 does destination based forwarding. SRH has forwarding instructions. CRH has forwarding methods. Which seems to indicate that a tag can map to an arbitrary “forwarding“ instruction.

In any case, given that every node needs to be programmed this is far from generic. 

Is it an option to make it generic? Not requiring the coordination? Along the lines of what Tom is proposing?

> Therefore, if CRH can be deployed in the absence of any routing protocol at all  (i.e., with static routes and a statically configured CRH-FIB), it is not SPRING.

Cheers 
Ole

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 13 May 2020 17:16:22 +0000

Hi Ron,

I'm still trying to figure out where you're going with this.
First it was SRm6, then an RH0 replacement, then not an RH0 replacement (in the 6man meeting), then it sort of is...

So I'm hoping you'll update the draft so I can understand a bit more:
- CRH has nothing to do with RH0.
- CRH operates only within a limited domain.

Anything else to clarify from others comments would help too.

Thanks
  Darren

On May 12, 2020, at 5:36 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Ole, Darren,

                                                                                   Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 12, 2020 4:38 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

Hi Ron,

     - Its size
     - Its security issues

Best regards,
Ole

---

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

Ole,

First, can we at least agree that CRH is not SPRING, because it doesn't rely on SPRING's control plane.

Once we establish that, I can address the other points.

                                                           Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan
Sent: Wednesday, May 13, 2020 1:09 PM
To: Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

Ron,

Cheers
Ole

>> REF: https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10__;!!NEt6yMaO-gk!R-N-KViI1KQrhZq4nzP7rQB5a6QqY2jsqeNXqPK8fqJPDq1gUClNhIjOI_w4L79x$
>>
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!R-N-KViI1KQrhZq4nzP7rQB5a6QqY2jsqeNXqPK8fqJPDq1gUClNhIjOI9Qu5sXb$

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

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 17:20:24 +0000

Darren,

What updates do you suggest?

                         Ron

Sent: Wednesday, May 13, 2020 1:16 PM

Hi Ron,

Thanks
  Darren

Ole, Darren,

                                                                                   Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 12, 2020 4:38 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

Hi Ron,

     - Its size
     - Its security issues

Best regards,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 May 2020 10:29:28 -0700

Hi,

> On May 13, 2020, at 10:16 AM, Darren Dukes (ddukes) <ddukes=[email-masked]> wrote:
> 
> Hi Ron,
> 

I think these are reasonable suggestions.

I also think only having one size would be helpful.

Bob

>> On May 12, 2020, at 5:36 PM, Ron Bonica <[email-masked]> wrote:
>> 
>> Ole, Darren,
>>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 13 May 2020 17:31:13 +0000

Hi Bob,

Please check inline

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: 13 May 2020 21:46
To: 6man <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

Gentlepeople,

I think the underlying question with CRH is does it conflict with what is being done in the Spring w.g.
[KT] IMHO we first need to understand what truly this new CRH (standalone ?) proposal is all about. The draft-bonica-6man-comp-rtg-hdr-13 seems to me like just the tip of an iceberg and not fully specified while previous versions provided a better picture in the SRm6 context.

To my thinking, what is being done in Spring is an architecture for distributing information that can be used to create source routes for SRH (RFC8754).  
[KT] Spring is defining the Source Routing architecture. It started with problem statement (RFC7855), use-cases (RFC8354) then the architecture (RFC8402) that also gave requirements for both data-planes (incl RFC8754) and also control plane for signalling and distribution of information.

 Anything that relies on that set of Spring routing protocols is part of the working being done in Spring.
[KT] The "Spring routing protocols" are nothing but OSPF, ISIS, BGP, PCEP, ..... These same protocols are going to be used for the distribution and advertisement of the CRH-FIB (ref https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-13#section-4). I think this is what some of the other comments have eluded to.

Likewise, to my thinking I don’t think that means that all new IPv6 routing headers conflict with the work being done in the Spring w.g.
[KT] Perhaps not and perhaps it would depend on the overall architecture since there were other new source RHs proposals also on the table? We have the precedence of RFC6275 and RFC6554. These RHs had WGs (similar to Spring) that defined their use-cases, architecture that covered applicability and requirements. Post that their respective RHs were specified. On the same lines SRH (RFC8754) was done in collaboration with Spring.

Thanks,
Ketan

Bob

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 13 May 2020 17:39:56 +0000

Ron, 

Isn't Spring's control plane the same that is being proposed for CRH (i.e. ISIS, OSPF, BGP, PCEP, etc.) ? Please list the protocols if CRH is using something different.

I am referring to your draft in LSR WG : https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/ ... where you have Prefix and Adjacency SIDs (same as SR-MPLS) to signal/distribute the SIDs that are used for provisioning the CRH-FIB.

Thanks,
Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: 13 May 2020 22:47
To: Ole Troan <[email-masked]>; Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ole,

                                                           Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan
Sent: Wednesday, May 13, 2020 1:09 PM
To: Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

Ron,

Cheers
Ole

---

From: [email-masked]
Date: Wed, 13 May 2020 19:42:34 +0200

Hi Ron,

> Once we establish that, I can address the other points.

I don't quite know what you mean by "CRH is not SPRING".
I am trying to prod at some of the claims in draft/presentation and on the list to see if I (and hopefully others) gain a better understanding of what CRH is and what problems it's meant to solve.

E.g the spring charter says:
"The SPRING WG defines procedures that allow a node to steer a packet
through an SR Policy instantiated as an ordered list of instructions
called segments and without the need for per-path state information to
be held at transit nodes."

Which I guess CRH also has with it's forwarding methods?
(that said you could probably do SR policy with RH0 too within a controlled domain, so perhaps the layout of the particular RH type isn't the distinguishing factor either. ;-))

Cheers,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 17:47:59 +0000

Ketan,

What makes you think that draft-bonica-lsr-crh-isis-extensions Has anything to do with SPRING. It is a control plane for the CRH.

                                                                               Ron

-----Original Message-----
From: Ketan Talaulikar (ketant) <ketant=[email-masked]> 
Sent: Wednesday, May 13, 2020 1:40 PM
To: Ron Bonica <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ron,

I am referring to your draft in LSR WG : https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/__;!!NEt6yMaO-gk!SVe-xsA7uJViDn_oPX0gsJeU2nZXMvSo5KNmXaXCltuyANiavEzfg7a5gXgIKcug$  ... where you have Prefix and Adjacency SIDs (same as SR-MPLS) to signal/distribute the SIDs that are used for provisioning the CRH-FIB.

Thanks,
Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: 13 May 2020 22:47
To: Ole Troan <[email-masked]>; Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ole,

                                                           Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan
Sent: Wednesday, May 13, 2020 1:09 PM
To: Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

Ron,

Cheers
Ole

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 13 May 2020 17:49:00 +0000

Hi Ron.

Just what I said…

Thanks!
  Darren

On May 13, 2020, at 1:20 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Darren,

                         Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 13, 2020 1:16 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

Hi Ron,

Thanks
  Darren

Ole, Darren,

                                                                                   Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 12, 2020 4:38 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

Hi Ron,

     - Its size
     - Its security issues

Best regards,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 May 2020 10:53:27 -0700

Ole,

There are also significant differences in the routing headers being
defined. Unlike SRH, CRH doesn't define its own TLVs, doesn't define
its own header authentication, and there's been no proposal AFAIK to
insert CRH extension headers in flight. IMO CRH is better aligned with
conforming to and leveraging the IPv6 protocol and its core
extensions.

Tom

---

From: Erik Kline <[email-masked]>
Date: Wed, 13 May 2020 10:56:21 -0700

I too find myself agreeing with Bob.

Two random comments:

  [1] there might be a better term than "compressed" with less baggage
(naming is hard)

  [2] for many, the architecture for distributing CP information is
"my SDN", so I'm not convinced all the CP distribution needs to be
worked out in advance

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 13 May 2020 18:09:02 +0000

Ron,

I get that impression since draft-bonica-lsr-crh-isis-extensions talks about Prefix and Adjacency SIDs which are Spring terms [1] and the protocol encodings you have proposed in that draft are identical semantically and encoding wise to the SR-MPLS extensions for ISIS.

May be you missed to define these different types of SIDs in https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-13#section-7 ? It would be good for the WG to understand what these CRH SIDs are all about if you elaborated them.

Thanks,
Ketan

[1] Please look for Prefix and Adjacency SID terms in https://tools.ietf.org/html/draft-bonica-lsr-crh-isis-extensions-02 and then look for the same terms in https://tools.ietf.org/html/rfc8402 and also https://tools.ietf.org/html/rfc8667

-----Original Message-----
From: Ron Bonica <rbonica=[email-masked]> 
Sent: 13 May 2020 23:18
To: Ketan Talaulikar (ketant) <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ketan,

                                                                               Ron

-----Original Message-----
From: Ketan Talaulikar (ketant) <ketant=[email-masked]> 
Sent: Wednesday, May 13, 2020 1:40 PM
To: Ron Bonica <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ron,

Thanks,
Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: 13 May 2020 22:47
To: Ole Troan <[email-masked]>; Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ole,

                                                           Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan
Sent: Wednesday, May 13, 2020 1:09 PM
To: Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

Ron,

Cheers
Ole

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 18:28:29 +0000

Bob,

I just posted version 16:

- tracker: https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/
- diff: https://www.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-16

It removes all references to RH0 and is more explicit about operating inside of a network domain for security reasons.

I still see a use case for the 32-bit SID, so I left that in the draft.

                                                                    Ron

-----Original Message-----
From: Bob Hinden <[email-masked]> 
Sent: Wednesday, May 13, 2020 1:29 PM
To: Darren Dukes (ddukes) <ddukes=[email-masked]>
Cc: Bob Hinden <[email-masked]>; Ron Bonica <[email-masked]>; 6man <[email-masked]>
Subject: Re: CRH and RH0

Hi,

Bob

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 18:32:01 +0000

Ketan,

In earlier versions of the draft, I called them Strictly Routed and Loosely Routed SIDs. This terminology was inherited from RFC 791.

Clearly, those concept existed thirty years ago, long before SR.

                                                                 Ron

-----Original Message-----
From: Ketan Talaulikar (ketant) <ketant=[email-masked]> 
Sent: Wednesday, May 13, 2020 2:09 PM
To: Ron Bonica <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ron,

May be you missed to define these different types of SIDs in https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-13*section-7__;Iw!!NEt6yMaO-gk!UFvH_dlQlNvqyIF4WbMpRzbk6gPBloUzAP6_5Xpn_EbfkAczhyQv11PRli_ym2B-$  ? It would be good for the WG to understand what these CRH SIDs are all about if you elaborated them.

Thanks,
Ketan

[1] Please look for Prefix and Adjacency SID terms in https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-lsr-crh-isis-extensions-02__;!!NEt6yMaO-gk!UFvH_dlQlNvqyIF4WbMpRzbk6gPBloUzAP6_5Xpn_EbfkAczhyQv11PRlgvNDkmY$  and then look for the same terms in https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8402__;!!NEt6yMaO-gk!UFvH_dlQlNvqyIF4WbMpRzbk6gPBloUzAP6_5Xpn_EbfkAczhyQv11PRlpb5jGn4$  and also https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8667__;!!NEt6yMaO-gk!UFvH_dlQlNvqyIF4WbMpRzbk6gPBloUzAP6_5Xpn_EbfkAczhyQv11PRlq1vucUt$

-----Original Message-----
From: Ron Bonica <rbonica=[email-masked]>
Sent: 13 May 2020 23:18
To: Ketan Talaulikar (ketant) <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ketan,

                                                                               Ron

-----Original Message-----
From: Ketan Talaulikar (ketant) <ketant=[email-masked]>
Sent: Wednesday, May 13, 2020 1:40 PM
To: Ron Bonica <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ron,

Thanks,
Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: 13 May 2020 22:47
To: Ole Troan <[email-masked]>; Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ole,

                                                           Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan
Sent: Wednesday, May 13, 2020 1:09 PM
To: Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

Ron,

Cheers
Ole

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 13 May 2020 18:41:35 +0000

Hi Tom.  Please see inline.

> On May 13, 2020, at 1:53 PM, Tom Herbert <[email-masked]> wrote:
> 
> defined. Unlike SRH, CRH doesn't define its own TLVs

I hear CRH is not as extendable as SRH...

> , doesn't define
> its own header authentication

I hear CRH is not as extendable as SRH...

> , and there's been no proposal AFAIK to
> insert CRH extension headers in flight.

Based on the current document only, and the apparent intent for it to stand on its own, I don’t really know what CRH is used for yet.  Who know what may happen.

> IMO CRH is better aligned with

I’m not sure how you think this.  Where are the IPv6 CP protocols that exchange 32bit identifiers representing IPv6 addresses?

OK, this is surprising… maybe these identifiers are IPv4 addresses and the draft intends to use IPv4 mapped IPv6 addresses within the domain?
Reusing the IPv4 IGPs would work for distribution, would any other control plane extensions be needed?
The thing is that without any description in the document it’s not clear to me where, how, or why it is to be used.

Darren

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 13 May 2020 18:44:10 +0000

Hi Ron,

Not that I wish to argue terminologies with you, but loosely routed and strictly routed (from RFC791) are very different from prefix and adjacency SIDs. Just because one uses an interface address of an intermediate node in the RH does not make the path strictly routed.

In any case, the draft under discussion is draft-bonica-6man-comp-rtg-hdr and it does not describe the SIDs (not even the loosely and strictly routed terminologies that you refer to). It would help understand how loose and strict routing is done with them. 

So could you please explain these semantics of the CRH SIDs in the document on your next update?

Thanks,
Ketan

-----Original Message-----
From: Ron Bonica <rbonica=[email-masked]> 
Sent: 14 May 2020 00:02
To: Ketan Talaulikar (ketant) <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ketan,

                                                                 Ron

-----Original Message-----
From: Ketan Talaulikar (ketant) <ketant=[email-masked]> 
Sent: Wednesday, May 13, 2020 2:09 PM
To: Ron Bonica <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ron,

Thanks,
Ketan

-----Original Message-----
From: Ron Bonica <rbonica=[email-masked]>
Sent: 13 May 2020 23:18
To: Ketan Talaulikar (ketant) <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ketan,

                                                                               Ron

-----Original Message-----
From: Ketan Talaulikar (ketant) <ketant=[email-masked]>
Sent: Wednesday, May 13, 2020 1:40 PM
To: Ron Bonica <[email-masked]>; Ole Troan <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ron,

Thanks,
Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: 13 May 2020 22:47
To: Ole Troan <[email-masked]>; Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: CRH and RH0

Ole,

                                                           Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan
Sent: Wednesday, May 13, 2020 1:09 PM
To: Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

Ron,

Cheers
Ole

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 13 May 2020 18:55:43 +0000

Hi Erik,

On your comment related to architecture, indeed the specific CP mechanism may come later. However, I find the proposal difficult to review and understand holistically without the architecture part (i.e. use-cases, applicability, semantics of the information being distributed, etc.).

The architecture used to be covered in draft-bonica-spring-sr-mapped-six but apparently that isn’t so anymore because that draft was about SPRING and now CRH is by itself?

Thanks,
Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Erik Kline
Sent: 13 May 2020 23:26
To: Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

Two random comments:

  [1] there might be a better term than "compressed" with less baggage (naming is hard)

  [2] for many, the architecture for distributing CP information is "my SDN", so I'm not convinced all the CP distribution needs to be worked out in advance

On Wed, May 13, 2020 at 9:27 AM Ron Bonica <rbonica=[email-masked]> wrote:
> Cc: Bob Hinden <[email-masked]>; Ron Bonica 
> <[email-masked]>; Robert Raszuk <[email-masked]>
> Subject: Re: CRH and RH0
>
> Gentlepeople,
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 19:58:13 +0000

Erik,

I could rename the CRH to something else. Maybe the Programmed Routing Header (PRH)? But would that make a difference to the folks who are voicing objections?

                                                 Ron

-----Original Message-----
From: Erik Kline <[email-masked]> 
Sent: Wednesday, May 13, 2020 1:56 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; 6man <[email-masked]>
Subject: Re: CRH and RH0

Two random comments:

On Wed, May 13, 2020 at 9:27 AM Ron Bonica <rbonica=[email-masked]> wrote:
> > REF: 
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica
> > -6man-comp-rtg-hdr-10__;!!NEt6yMaO-gk!QcAL7_ALlBjQGtAnsGVN1JsDVd305D
> > lUw8Cr1FGDjAbPI5e93Il4WpTsbTWL9bL9$
> >
> __;!!NEt6yMaO-gk!QcAL7_ALlBjQGtAnsGVN1JsDVd305DlUw8Cr1FGDjAbPI5e93Il4W
> pTsbVcgbtWl$

---

From: John Scudder <[email-masked]>
Date: Wed, 13 May 2020 19:59:53 +0000

I’m a little confused about this conversation and I’d like to ask the chairs for clarification. My actual questions are at the end of this long(ish) message, and can be summarized as (1) does 6man require consent from SPRING before defining routing headers, and (2) what criteria are the chairs using to decide when an adoption call is OK?

It seems to me there are at least two, only vaguely related, conversations going on. One of them is a debate about the assertion that 6man can’t even consider taking up CRH unless SPRING approves it. The other is a more free-wheeling line of questioning about “what is CRH for anyway”? 

I presume both of these relate to Ron’s request for an adoption call. Here’s what the minutes from the interim have:

> Bob: Thank you Ron. I think it's too early for adoption call.
> 
> Ron: What is needed to get to adoption call.
> 
> Bob: I can't answer right now.
> 
> Ron: Can I ask on list?
> 
> Bob: OK.
> 
> Ole: Related to what's going on in spring.

Too bad we have no audio recording, but that’s not too far from my recollection. Anyway, I don’t think I’ve seen this answered on list yet, so I’m asking again.

Regarding the SPRING-related process stuff:

I have quite a bit of history with how SPRING was chartered; I was one of the original co-chairs and helped write the charter, god help me. I can tell you for certain there was no intent that SPRING should have exclusive ownership of source routing in the IETF, the name isn’t a power-grab, it’s a clever backronym, as we do in the IETF. If one entity in the IETF were to take charge of all source routing, that sounds more like a new area than a WG. But don’t take my word for it, go read the various iterations of the charter. As anyone who’s looked at the Segment Routing document set can tell, Segment Routing is one, very specific, way of doing source routing. As Ketan and others have pointed out, it’s a pile of architecture plus the bits and pieces to instantiate that architecture. That is fine, but the idea that merely because a technology might be used to instantiate part of that architecture, it’s owned by SPRING, is overreach. Just because a sandwich is a filling between two pieces of starch, doesn’t mean every filling between two pieces of starch is a sandwich. [1]

But at any rate, the question for the chairs is: do you think 6man needs SPRING’s permission in order to consider adopting CRH? Does 6man need permission from SPRING for all routing headers, or just some, and if it’s just some, what characterizes them?

Regarding the more general “what is CRH for anyway” stuff:

This seems to me to be exactly the kind of discussion one would normally have in the context of an adoption call. Why is it not being had in that context? To rewind back to the interim, if it’s still “too early for adoption call”, what has to happen for it not to be too early?

Thanks,

—John

[1] https://cuberule.com

---

From: Mark Smith <[email-masked]>
Date: Thu, 14 May 2020 06:09:28 +1000

Compact Routing Header.

On Thu, 14 May 2020, 05:58 Ron Bonica, <rbonica=[email-masked]>
wrote:

> Erik,
>
> I could rename the CRH to something else. Maybe the Programmed Routing
> Header (PRH)? But would that make a difference to the folks who are voicing
> objections?
>
>                                                  Ron
>
>
>
>   [2] for many, the architecture for distributing CP information is "my
> SDN", so I'm not convinced all the CP distribution needs to be worked out
> in advance
>
> > Therefore, if CRH can be deployed in the absence of any routing protocol
> at all  (i.e., with static routes and a statically configured CRH-FIB), it
> is not SPRING.
> >
> >
>
> > Ron
> >
> >
> >
> > IPv6 routing headers starting with RFC1883 published in 1995 used the
> term “segments” to identify elements in the list of addresses.   In that
> sense, all IPv6 routing headers do some form of segment routing.  It’s a
> generic term that has been around for 25 years.
> >
> > To my thinking, what is being done in Spring is an architecture for
> distributing information that can be used to create source routes for SRH
> (RFC8754).   Anything that relies on that set of Spring routing protocols
> is part of the working being done in Spring.
> >
> > Likewise, to my thinking I don’t think that means that all new IPv6
> routing headers conflict with the work being done in the Spring w.g.
> >
> > Bob
> >
> >
> > > Oh - haven't we established just yesterday that you will not be
> referencing RH0 any longer with CRH proposal  ?
> > >
> > > It's like you are trying to build a vehicle  .. it has wheels,
> steering and even seats (no engine and no belts for now). But you keep
> insisting - it is not a car.
> > >
> > > See if you put normative reference to segment routing up to version
> -10 then suddenly drop it with no major change to the body of the draft the
> > > Your draft only talks about SIDs and segments so no matter how you
> call it the core purpose is segment routing.
> > >
> > >
> > >
> > > Take care,
> > > R.
> > >
> > >
> > >
> > > Given that it is only fifteen pages long, I suspect that progressing
> it would be less work than arguing about whether to progress it.
> > >
> > >
> > >
> > > So it is clear that you are not just trying to fix suboptimalities of
> IPv6 encoding out of the woods. The goal is clear to get this in and use it
> as a hook to show in SPRING and other routing WGs in IETF that since you
> have CRH accepted as a WG docs in 6man other groups should follow along and
> work on SRm6 encodings.
> > >
> > >
> > >
> > > The mapping plane between SIDs and labels is already in place in
> SR-MPLS. Just changing few bit here and there does not make new proposal to
> stand on its own.
> > >
> > >
> > >
> > > I think it has been clearly stated by 6man chairs and AD that any work
> on SRm6 can be taken on only after SPRING WG accepts the main concept and

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 May 2020 22:12:02 +0200

John,

May I add one more perspective to this.

6man just standardized SRH. Why SRH content can not be filled by controller
and used for the very same purpose as authors intend to use CRH for ?

Oh one may say there is no compression there ... If so I recommend to take
a look at uSID and vSID proposals.

Is it in good interest of anyone deploying segment routing to have to deal
with N different non interoperable headers ? Does it make anyone's life
easier ?

Kind regards,
Robert.

PS. So my own side observation lead me to believe it is not about "too
early to ask for adoption" ... it is actually "way too late"

On Wed, May 13, 2020 at 10:01 PM John Scudder <jgs=
[email-masked]> wrote:

> I’m a little confused about this conversation and I’d like to ask the
> chairs for clarification. My actual questions are at the end of this
> long(ish) message, and can be summarized as (1) does 6man require consent
> from SPRING before defining routing headers, and (2) what criteria are the
> chairs using to decide when an adoption call is OK?
>
> It seems to me there are at least two, only vaguely related, conversations
> going on. One of them is a debate about the assertion that 6man can’t even
> consider taking up CRH unless SPRING approves it. The other is a more
> free-wheeling line of questioning about “what is CRH for anyway”?
>
> I presume both of these relate to Ron’s request for an adoption call.
> Here’s what the minutes from the interim have:
>
> Too bad we have no audio recording, but that’s not too far from my
> recollection. Anyway, I don’t think I’ve seen this answered on list yet, so
> I’m asking again.
>
> I have quite a bit of history with how SPRING was chartered; I was one of
> the original co-chairs and helped write the charter, god help me. I can
> tell you for certain there was no intent that SPRING should have exclusive
> ownership of source routing in the IETF, the name isn’t a power-grab, it’s
> a clever backronym, as we do in the IETF. If one entity in the IETF were to
> take charge of all source routing, that sounds more like a new area than a
> WG. But don’t take my word for it, go read the various iterations of the
> charter. As anyone who’s looked at the Segment Routing document set can
> tell, Segment Routing is one, very specific, way of doing source routing.
> As Ketan and others have pointed out, it’s a pile of architecture plus the
> bits and pieces to instantiate that architecture. That is fine, but the
> idea that merely because a technology might be used to instantiate part of
> that architecture, it’s owned by SPRING, is overreach. Just because a
> sandwich is a filling between two pieces of starch, doesn’t mean every
> filling between two pieces of starch is a sandwich. [1]
>
> But at any rate, the question for the chairs is: do you think 6man needs
> SPRING’s permission in order to consider adopting CRH? Does 6man need
> permission from SPRING for all routing headers, or just some, and if it’s
> just some, what characterizes them?
>
> This seems to me to be exactly the kind of discussion one would normally
> have in the context of an adoption call. Why is it not being had in that
> context? To rewind back to the interim, if it’s still “too early for
> adoption call”, what has to happen for it not to be too early?
>
> Thanks,
>
> —John
>
> [1] https://cuberule.com

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 May 2020 22:16:12 +0200

> Compact Routing Header.

I am actually completely shocked what happened and why is it not being
called *SRH+* ....

;-)

Take care,
R.

On Wed, May 13, 2020 at 10:09 PM Mark Smith <[email-masked]> wrote:

> Compact Routing Header.
>
> On Thu, 14 May 2020, 05:58 Ron Bonica, <rbonica=
>> > Therefore, if CRH can be deployed in the absence of any routing
>> protocol at all  (i.e., with static routes and a statically configured
>> CRH-FIB), it is not SPRING.
>> >
>> >
>>
>> > Ron
>> >
>> >
>> >
>> > > I think it has been clearly stated by 6man chairs and AD that any
>> work on SRm6 can be taken on only after SPRING WG accepts the main concept
>> and adopts the main doc as a WG item.
>> > >
>> > >
>> > >

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 20:30:14 +0000

Mark,

That works for me. And it allows me to retain the acronym.

Does Compact Routing Header work for everyone else?

                                              Ron

Juniper Business Use Only
From: Mark Smith <[email-masked]>
Sent: Wednesday, May 13, 2020 4:09 PM
To: Ron Bonica <[email-masked]>
Cc: Erik Kline <[email-masked]>; 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

Compact Routing Header.
On Thu, 14 May 2020, 05:58 Ron Bonica, <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Erik,

                                                 Ron

-----Original Message-----
From: Erik Kline <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 13, 2020 1:56 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

Two random comments:

On Wed, May 13, 2020 at 9:27 AM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
> From: Bob Hinden <[email-masked]<mailto:[email-masked]>>
> To: 6man <[email-masked]<mailto:[email-masked]>>
> Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; Ron Bonica
> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
> Subject: Re: CRH and RH0
>
> Gentlepeople,
>
> IPv6 routing headers starting with RFC1883 published in 1995 used the term "segments" to identify elements in the list of addresses.   In that sense, all IPv6 routing headers do some form of segment routing.  It's a generic term that has been around for 25 years.
>
> Likewise, to my thinking I don't think that means that all new IPv6 routing headers conflict with the work being done in the Spring w.g.
>
> Bob
>
>
> > On May 13, 2020, at 8:55 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Ron,
> >
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica>
> [email-masked]<mailto:[email-masked]>
> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__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://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!VHmP3PcVAJw1finsVBIZbaA0e4G5zZU4In-iGsakGYvgMBLd5xSFypEs7dSATjx4$>
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 20:39:59 +0000

Robert,

As Darren points out, the SRH has so much stuff that CRH lacks:

  *   Tags
  *   Flags
  *   TLVs

The CRH is a humble routing header that steers a packet along a delivery path. It can be describe in fourteen pages, with lots of white space.

Maybe it should be called the Unpretentious Routing Header (URH) 😉

                                                                 Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Wednesday, May 13, 2020 4:16 PM
To: Mark Smith <[email-masked]>
Cc: Ron Bonica <[email-masked]>; 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

> Compact Routing Header.

I am actually completely shocked what happened and why is it not being called SRH+ ....

;-)

Take care,
R.

On Wed, May 13, 2020 at 10:09 PM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
Compact Routing Header.
On Thu, 14 May 2020, 05:58 Ron Bonica, <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Erik,

                                                 Ron

-----Original Message-----
From: Erik Kline <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 13, 2020 1:56 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

Two random comments:

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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 13 May 2020 16:42:02 -0400

Spring folks,

I am working on a Spring draft that compares SRv6, SR-MPLS and CRH.

This draft will clearly answer all of the questions that are being asked
related to CRH.

This draft is from an unbiased view of the MPLS replacement flavors
mentioned and a decision tree from an operators perspective how to pick and
which to pick based on business requirements and use cases presented.  They
all have their merits and they all have their caveats pros and cons all of
which will be documented in the draft to help operators.

This draft is focused on MPLS replacement so will only touch on use cases
outside of MPLS replacement.  CRH can be used more ubiquitously for any use
case independent or MPLS which is what makes it shine along with its
simplicity over the others

Kind regards

Gyan

On Wed, May 13, 2020 at 4:30 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> *From:* Mark Smith <[email-masked]>
> *Sent:* Wednesday, May 13, 2020 4:09 PM
> *Cc:* Erik Kline <[email-masked]>; 6man <[email-masked]>; Bob Hinden <
> [email-masked]>
> [email-masked]..org <[email-masked]>> wrote:
>
> Erik,
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!VHmP3PcVAJw1finsVBIZbaA0e4G5zZU4In-iGsakGYvgMBLd5xSFypEs7dSATjx4$>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Wed, 13 May 2020 13:52:20 -0700

Dear 6MAN Working Chairs,

During the last 6MAN, there was a comment about the Working Chair 
about it being too early to have an adoption call for 
draft-bonica-6man-comp-rtg-hdr.  Could the Working Chairs please 
provide some information about their decision as there isn't any 
information about that in the minutes?

I could not find the attendance list for the working group meeting 
which was held on May 5.  Isn't it an IETF requirement to publish 
that information?

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 May 2020 09:06:01 +1200

On 14-May-20 07:59, John Scudder wrote:
...
> But at any rate, the question for the chairs is: do you think 6man needs SPRING’s permission in order to consider adopting CRH? 

No, of course not. But the final decision is made by IETF consensus, not by WG consensus.

   Brian

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 13 May 2020 21:54:24 +0000

Hi John, my 2 cents.

Last week someone came to the working group and said “here is a new routing header, it carries opaque numbers that get mapped to IPv6 addresses and some other stuff.  Please adopt it.”

Now the WG is asking what this thing is, what is the author's intent, how does it fit into other work ongoing in 6MAN and other working groups.

Contrast this with every other routing header defined that has come from a WG with a plan for how it is to be used and usecases for it:
Type0 - IPNG
RPL - ROLL
Type2 - MEXT
SRH - SPRING

CRH seems out of place...

Does CRH even fit in the 6man charter?  It doesn’t appear so, it looks to me like the tip of an iceberg.
"It (6man) is not chartered to develop major changes or additions
to the IPv6 specifications.”

Darren

> On May 13, 2020, at 3:59 PM, John Scudder <jgs=[email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 May 2020 18:00:52 -0400

Darren, the CRH routing header has been on the table for a LOT longer 
than "last week".  And has been presented at previous IETF meetings.

You have the write to ask for clarifications.  In an earlier message you 
made two specific requests.  Fair.  But please do not recast history.

Yours,
Joel

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 13 May 2020 22:00:42 +0000

Hi Ron, like Shuping mentioned, SHR has an architecture document (RFC8402), problem statement (RFC7855) and use cases in RFC8354 & RFC8355 to justify need for a SRH (RFC8754).

CRH now has none.  Where are its architecture, applicability statement, use-cases documents?  This will let the WG evaluate the overall solution.
You used to have a normative reference to SRm6 but you removed it apparently to distance this work from SPRING and SRm6.

Darren

On May 13, 2020, at 4:39 PM, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Robert,

  *   Tags
  *   Flags
  *   TLVs

                                                                 Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 13, 2020 4:16 PM
To: Mark Smith <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; Bob Hinden <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

;-)

Take care,
R.

                                                 Ron

-----Original Message-----
From: Erik Kline <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 13, 2020 1:56 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

Two random comments:

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 May 2020 10:27:58 +1200

Oops, I should have said IMHO since I am certainly not a chair...

Regards
   Brian

---

From: John Scudder <[email-masked]>
Date: Wed, 13 May 2020 22:51:24 +0000

Brian,

> On May 13, 2020, at 5:06 PM, Brian E Carpenter <[email-masked]> wrote:
> 

That is true of document advancement to RFC. I’m talking about WG draft adoption.

—John

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 May 2020 16:03:01 -0700

Hi,

> On May 13, 2020, at 1:52 PM, S Moonesamy <[email-masked]> wrote:
> 
> During the last 6MAN, there was a comment about the Working Chair about it being too early to have an adoption call for draft-bonica-6man-comp-rtg-hdr.  Could the Working Chairs please provide some information about their decision as there isn't any information about that in the minutes?

We were asked about this and said we didn’t have an answer.  We are working on this.

> 
> I could not find the attendance list for the working group meeting which was held on May 5.  Isn't it an IETF requirement to publish that information?

The bluesheet was published right after the meeting.  See:

https://datatracker.ietf.org/meeting/interim-2020-6man-02/session/6man

Bob

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 May 2020 16:13:45 -0700

John,

> On May 13, 2020, at 12:59 PM, John Scudder <[email-masked]> wrote:
> 

Good to know.

> But at any rate, the question for the chairs is: do you think 6man needs SPRING’s permission in order to consider adopting CRH? Does 6man need permission from SPRING for all routing headers, or jus…

In my view, the general answer to that is no, we don’t need the Spring w.g. permission to consider adopting a new routing header.   If a draft came along that was proposing to update SRH (RFC 8754) we would want to discuss it with the Spring w.g.

In my reading of the current version of CRH, it is not proposing to update RFC 8754.

> This seems to me to be exactly the kind of discussion one would normally have in the context of an adoption call. Why is it not being had in that context? To rewind back to the interim, if it’s sti…

Seems like we are having this discussion now even without a formal adoption call.

Ole and I are discussing this tomorrow.

Bob

---

From: S Moonesamy <[email-masked]>
Date: Wed, 13 May 2020 16:27:05 -0700

Hi Bob,
At 04:03 PM 13-05-2020, Bob Hinden wrote:
>We were asked about this and said we didn't have an answer.  We are 
>working on this.

Ok.

>https://datatracker.ietf.org/meeting/interim-2020-6man-02/session/6man

Thanks for the link.

Regards,
S. Moonesamy

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 May 2020 17:25:26 -0700

Darren,

My comparison was with respect to the data plane protocols,
particularly draft-bonica-6man-comp-rtg-hdr-18 and RFC8754.

Tom

 and directed to the routing header format itself, specifically that defined by

---

From: Ron Bonica <[email-masked]>
Date: Thu, 14 May 2020 01:30:22 +0000

Darren,

If I were to add the following sections to the draft, would they address your concern. If not, what else is needed? Please be specific.

                                                                          Ron

PROPOSED TEXT
----------------------

9.0 Applicability

The CRH can be used within any network where:

  *   All nodes implement IPv6.
  *   Edge node can filter inbound packets that contain the CRH.
  *   Selected nodes can process the CRH. If a node is identified in a CRH, and it is not the packet’s ultimate destination, it must be able to process the CRH.
  *   All nodes can maintain a basic FIB that maps IPv6 prefixes to next-hops.
  *   All nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses and forwarding methods
  *   CRH overhead is acceptable
CRH-16  overhead is as follows:

  *   2 SIDs can be stored in a 8-byte CRH
  *   6 SIDs can be stored in a 16-byte CRH
  *   10 SIDs can be stored in a 24-byte CRH
  *   14 SIDs can be stored in a 32-byte CRH
  *   Etc.
CRH-32  overhead is as follows:

  *   1 SIDs can be stored in a 8-byte CRH
  *   3 SIDs can be stored in a 16-byte CRH
  *   5 SIDs can be stored in a 24-byte CRH
  *   7 SIDs can be stored in a 32-byte CRH
  *   Etc.
10.0 Use-cases

The CRH can be used to provide traffic steering in:

  *   Data centers
  *   Service provider networks
  *   Enterprise networks
Each of these networks may have a preferred method for populating the basic FIB and the CRH-FIB. For example, a data center may use a controller to populate both FIBs while a service provider may use an IGP to populate both FIBs.
The CRH can implemented on:

  *   ASIC-based routers
  *   Software-based routers
     *   Stand-alone
     *   In a container on a server in a data center

11.0 Architecture

CRH architecture determined entirely by RFC 8200. Specifically:

  *   IPv6 source nodes use the CRH to determine intermediate nodes that a packet visits on route to is ultimate destination.
  *   The CRH does not subsume the function of any other IPv6 extension header. For example, the CRH cannot be used for authentication, or to deliver optional internet-layer information to the packet’s ultimate destination node.
  *   A packet that contains the CRH can also contain any valid combination of IPv6 extension headers. All extension header should function as per their specifications.
  *   The CRH assumes that IPv6 Destination Address semantics are as defined in RFC 8200 and RFC 4291.
  *   The CRH is processed identically on every node (See Section 5 of this document). Processing rules do not depend upon information encoded in the IPv6 Destination Address.

The CRH conforms to the letter and spirit of RFC 8200. For example:

  *   A packet cannot contain two instances of the CRH
  *   A CRH cannot be added or deleted by any node along a packet’s processing path

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Wednesday, May 13, 2020 6:01 PM
To: Ron Bonica <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Mark Smith <[email-masked]>; 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: CRH and RH0

Darren

Robert,

  *   Tags
  *   Flags
  *   TLVs

                                                                 Ron

;-)

Take care,
R.

                                                 Ron

-----Original Message-----
From: Erik Kline <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 13, 2020 1:56 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

Two random comments:

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RFHzGcUlAy_yKte9j0LvSMyl512vVcOHpMtJNak9PgeVCPi4-rmsxuwpNLvR631g$>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 14 May 2020 05:31:41 +0000

Hi John/Bob,

I see that the key conversations that have been going around are to get a better description and specification of this new CRH "standalone" proposal that is claimed to be independent of SPRING work. This fundamental change happened in mid-February and was only presented a little over a week ago. So I do agree with what Bob mentioned in the interim that it was too early for adoption call.

Right now, the CRH draft in its current "standalone" form does not seem to be reflecting a proper and full picture. Since this is a Routing Header, there are routing aspects that need clarity and it is not just about the header. 

So IMHO, it seems like a perfectly reasonable conversation to be had at this time - after all the authors did request for review? 

This way the WG has, before it, a document that sufficiently describes the proposal. This will help the WG to know exactly what is the nature of this work and its implications - especially the routing and operational aspects.

It is encouraging to see the authors engaging in capturing the feedback and updating the document. So we are making progress here and given how recent this shift from SRm6 to CRH "standalone" has been, I hope there is no pressure on the WG to consider adoption.

Thanks,
Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: 14 May 2020 04:44
To: John Scudder <[email-masked]>
Cc: [email-masked]; Bob Hinden <[email-masked]>; [email-masked]
Subject: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

John,

Good to know.

Bob

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 14 May 2020 07:28:35 +0000

Why do we even need to ask such a question: whether the Chairs of the WG A will need the permission from WG B to do their job in their own WG? We all know the answer.

But do the Chairs of a WG need to be aware of what are currently happening in other WGs in IETF and then evaluate the relationship or influence on the work in their own WG? It SHOULD be YES. Do you agree?

The responses from the Chairs on the WG adoption call, as being cited here below, to me are based on their judgements obtained from the discussions during the virtual meeting as well as what have been happening in the WG and other WGs. These are reasonable responses to me. 

It is true that the CRH has been there for some time. But the virtual meeting only passed less than ten days, I don’t see why it could suddenly become not "too early for adoption call" and suddenly "what's going on in SPRING" just disappear.

OK, now let's focus on the issue to be solved. To me it has always been the core role of IETF. When there is an issue in real world, the engineers here in IETF will come up with drafts describing solutions to try to solve the issue in a standard way and make it interoperable among different vendors. That is how today's Internet is built. There is no reason to change it just because of the discussions being carried in tons of emails every day in this mailing list.

What is the issue to be solved? To me it is very simple and crystal clear: the lengthy header. When people start putting the IPv6 address as segments in the RH, the header becomes especially "too" long which introduces overhead and the transmission efficiency becomes low and it is not acceptable to some operators in some scenarios. Then people start come up with solutions to try to solve this particular issue.

For now there are a few typical solutions on the table, just to abstract, they are mapping, stitching, shifting. It is true that they are currently in different WGs. But they are solving the same issue, i.e. the potential lengthy header imposed by RH. From this point of view, should people discuss these solutions altogether and come up with agreements first and then proceed in IETF?

People here seem to like the simple and hard-ware friendly solutions very much. It is understandable, but here are a few observations from myself.

From the service requirements wise, we are in the 5G era now and some people are even talking about 6G, ever-emerging diverse applications with various requirements are accessing to the network and imposing demanding requirements on the network. That is the challenge but also the opportunity to the network community. Why does the network still just want to a simple mechanism only perform the delivery of the packets from S to D?

From the hardware wise, we are not using the chipset 25 years ago. The hardware nowadays is high-performance and can be programmable. They can provide more capabilities at the same time in line rate. Why we don’t want to take advantage of this capability to bring more innovations into the network? 

OK, it is very simple to have the RH only dealing with the packet steering and no programmability at all simply because it seems not to be real and too complex to handle. But do the operators want to provide services other than simple packet steering? Of course yes, right? At least you will need to provide VPN. 

How to support VPN? Simple, with DOH to carry VPN. But with SRv6 BE, you could just use a single Destination Address to indicate both routing and VPN. Yes, BE is not enough, and you want TE. OK, if you put VPN in DOH and segments in RH. There will be two headers coexisting in parallel, and the DOH is a TLV. How about the forwarding performance? So do we need to evaluate which solution is more simple and hardware-friendly on earth? Please don’t forget about the compatibility and interoperability in the real deployments either. 

At last, for the mapping solution, will every single node be required to keep a mapping table for forwarding? Is it really that simple?

Sorry for this lengthy email...

Best regards, 
Shuping 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Thursday, May 14, 2020 4:00 AM
To: [email-masked]
Cc: [email-masked]
Subject: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Thanks,

—John

[1] https://cuberule.com

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 14 May 2020 11:34:59 +0000

Joel. It is not me who is recasting history. You forget that the CRH has been the routing header for srm6 up until last weeks presentation.

Last week it was presented as a general replacement for RH0 with no association to srm6.

Is it still solely the srm6 routing header?

Darren
________________________________
From: Joel M. Halpern <[email-masked]>
Sent: Wednesday, May 13, 2020 6:01 PM
To: Darren Dukes (ddukes)
Cc: [email-masked]
Subject: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Yours,
Joel

---

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

Hi 6man,

I think we all need time to read the drafts to catch up the development of the tech, it seems like some revisions are just posted with modifications.

Also, things are going strange. IMHO, Mailing list is used for discussing tech? But right now it is not like a tech discussion but something else.

BTW, may be better to discuss the stable name for CRH, I feel hard to learn new words. English is not my mother language☹

Best,
Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, May 14, 2020 4:40 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Mark Smith <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>; Bob Hinden <[email-masked]<mailto:[email-masked]>>
Subject: RE: CRH and RH0

Robert,

-          Tags
-          Flags
-          TLVs

                                                                 Ron

;-)

Take care,
R.

                                                 Ron

-----Original Message-----
From: Erik Kline <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 13, 2020 1:56 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: CRH and RH0

Two random comments:

---

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

Hi Chairs,

Many thanks for the link and your work! Finally have the minutes. 

Will reply to the mailing list to address the comments of G-SRv6 ASAP.

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Thursday, May 14, 2020 7:03 AM
To: S Moonesamy <[email-masked]>
Cc: [email-masked]; Bob Hinden <[email-masked]>; [email-masked]
Subject: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Hi,

Bob

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 May 2020 14:39:28 +0200

Dear Ron,

Two questions:

*The CRH can be used within any network where:*

   - *All nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses and
   forwarding methods*

Can you confirm that if I have at least one node which can not maintain
CRH-FIB CRH can not be used in the entire network ? To me that is
sever limitation and deployment blocker. Are you saying that legacy node -
pure IPv6 transit - can not just forward based on the DA address and must
always inspect CRH ?

*The CRH can be used to provide traffic steering in:*

   - *Data centers*
   - *Service provider networks*
   - *Enterprise networks*

Is there any reason why you have not listed "Home networks" and "Lab
networks" ?

Many thx,
R.

On Thu, May 14, 2020 at 3:30 AM Ron Bonica <[email-masked]> wrote:

> Darren,
>
>
>
> If I were to add the following sections to the draft, would they address
> your concern. If not, what else is needed? Please be specific.
>
>
>
>
>                                   Ron
>
>
>
> PROPOSED TEXT
>
> ----------------------
>
>
>
> 9.0 Applicability
>
>
>
>    - All nodes implement IPv6.
>    - Edge node can filter inbound packets that contain the CRH.
>    - Selected nodes can process the CRH. If a node is identified in a
>    CRH, and it is not the packet’s ultimate destination, it must be able to
>    process the CRH.
>    - All nodes can maintain a basic FIB that maps IPv6 prefixes to
>    next-hops.
>    - All nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses
>    and forwarding methods
>    - CRH overhead is acceptable
>
>    - 2 SIDs can be stored in a 8-byte CRH
>    - 6 SIDs can be stored in a 16-byte CRH
>    - 10 SIDs can be stored in a 24-byte CRH
>    - 14 SIDs can be stored in a 32-byte CRH
>    - Etc.
>
>    - 1 SIDs can be stored in a 8-byte CRH
>    - 3 SIDs can be stored in a 16-byte CRH
>    - 5 SIDs can be stored in a 24-byte CRH
>    - 7 SIDs can be stored in a 32-byte CRH
>    - Etc.
>
> 10.0 Use-cases
>
>
>
>    - Data centers
>    - Service provider networks
>    - Enterprise networks
>
> Each of these networks may have a preferred method for populating the
> basic FIB and the CRH-FIB. For example, a data center may use a controller
> to populate both FIBs while a service provider may use an IGP to populate
> both FIBs.
>
>    - ASIC-based routers
>    - Software-based routers
>       - Stand-alone
>       - In a container on a server in a data center
>
>
>
>
>
> 11.0 Architecture
>
>
>
>    - IPv6 source nodes use the CRH to determine intermediate nodes that a
>    packet visits on route to is ultimate destination.
>    - The CRH does not subsume the function of any other IPv6 extension
>    header. For example, the CRH cannot be used for authentication, or to
>    deliver optional internet-layer information to the packet’s ultimate
>    destination node.
>    - A packet that contains the CRH can also contain any valid
>    combination of IPv6 extension headers. All extension header should function
>    as per their specifications.
>    - The CRH assumes that IPv6 Destination Address semantics are as
>    defined in RFC 8200 and RFC 4291.
>    - The CRH is processed identically on every node (See Section 5 of
>    this document). Processing rules do not depend upon information encoded in
>    the IPv6 Destination Address.
>
>
>
>    - A packet cannot contain two instances of the CRH
>    - A CRH cannot be added or deleted by any node along a packet’s
>    processing path
>
>
>
>
>
> *From:* Darren Dukes (ddukes) <ddukes=[email-masked]>
> *Sent:* Wednesday, May 13, 2020 6:01 PM
> *Cc:* Robert Raszuk <[email-masked]>; Mark Smith <
> [email-masked]>; 6man <[email-masked]>; Bob Hinden <
> [email-masked]>
> Hi Ron, like Shuping mentioned, SHR has an architecture document
> (RFC8402), problem statement (RFC7855) and use cases in RFC8354 & RFC8355
> to justify need for a SRH (RFC8754).
>
> CRH now has none.  Where are its architecture, applicability statement,
> use-cases documents?  This will let the WG evaluate the overall solution.
>
> You used to have a normative reference to SRm6 but you removed it
> apparently to distance this work from SPRING and SRm6.
>
>
>
> Darren
>
>
>
> On May 13, 2020, at 4:39 PM, Ron Bonica <
> rbonica=[email-masked]> wrote:
>
>
>
> Robert,
>
>
>
> The CRH is a humble routing header that steers a packet along a delivery
> path. It can be describe in fourteen pages, with lots of white space.
>
>
>
> *Sent:* Wednesday, May 13, 2020 4:16 PM
> *To:* Mark Smith <[email-masked]>
> *Cc:* Ron Bonica <[email-masked]>; 6man <[email-masked]>; Bob Hinden <
> [email-masked]>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TjE3Uqlf3fJa9c2ENZOsvyJsNfZo_fj0sAV2EQTo1IIC8Q3TyFLz3m5vPgpU7JdB$>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TjE3Uqlf3fJa9c2ENZOsvyJsNfZo_fj0sAV2EQTo1IIC8Q3TyFLz3m5vPgpU7JdB$>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RFHzGcUlAy_yKte9j0LvSMyl512vVcOHpMtJNak9PgeVCPi4-rmsxuwpNLvR631g$>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 May 2020 14:10:45 +0100

> On 14 May 2020, at 13:39, Robert Raszuk <[email-masked]> wrote:
> 
> All nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses and forwarding methods
> Can you confirm that if I have at least one node which can not maintain CRH-FIB CRH can not be used in the entire network ? To me that is sever limitation and deployment blocker. Are you saying that legacy node - pure IPv6 transit - can not just forward based on the DA address and must always inspect CRH ?

How could *all* ever be the case? Surely it is the same as SRv6 in that nodes that do not understand the EH just forward the packet on the best effort path, and nodes instantiating the path need to take that into consideration.

Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 May 2020 15:37:52 +0200

Stewart,

> How could *all* ever be the case?

I am reading what Ron wrote and asking to clarify what he meant when he
wrote it.

Thx

On Thu, May 14, 2020 at 3:10 PM Stewart Bryant <[email-masked]>
wrote:

>    - *All nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses
>    and forwarding methods*
>
> How could *all* ever be the case? Surely it is the same as SRv6 in that
> nodes that do not understand the EH just forward the packet on the best
> effort path, and nodes instantiating the path need to take that into
> consideration.
>
> Stewart
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 May 2020 14:55:07 +0100

I suspect a slip of the proverbial pen.

S

> On 14 May 2020, at 14:37, Robert Raszuk <[email-masked]> wrote:
> 
> Stewart,
> 
> I am reading what Ron wrote and asking to clarify what he meant when he wrote it. 
> 
> Thx
> 
> 
> 
> 
> On Thu, May 14, 2020 at 3:10 PM Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 14 May 2020, at 13:39, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 14 May 2020 09:43:07 -0500

On Wed, May 13, 2020 at 6:03 PM Bob Hinden <[email-masked]> wrote:

> > During the last 6MAN, there was a comment about the Working Chair about
> it being too early to have an adoption call for
> draft-bonica-6man-comp-rtg-hdr.  Could the Working Chairs please provide
> some information about their decision as there isn't any information about
> that in the minutes?
>
> > I could not find the attendance list for the working group meeting which
> was held on May 5.  Isn't it an IETF requirement to publish that
> information?
>

When I joined there were 60+ people in the call but only app 43  of them
signed up.

Regards,
Behcet

---

From: "Voyer, Daniel" <[email-masked]>
Date: Thu, 14 May 2020 14:50:49 +0000

Chairs,

>>snip

If you are reviewing this today ( I presume you are doing it now), can you consider the following:

There have been many outstanding technical comments that authors have not addressed (this is a partial list).

Robert Raszuk on the many extensions required by CRH (IGP, BGP, OAM) https://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE
Robert Raszuk and Dirk Steinberg on CRH being a poor re-engineering of SR-MPLS over IP/UDP
Robert: https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo
Dirk: https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM
Dan Voyer reminding that SRv6 is a mature technology (deployments, long IETF work), as opposed to CRH https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4
Zhibo Hu on the many advantages of SRv6 https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ
Cheng Li expressing concerns on the dataplane performance of CRH https://mailarchive.ietf.org/arch/msg/spring/XK0F40oEuZv-3ule-X5685d_6Mc
Zafar summarizing the main issues of CRH https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4
Wim Henderickx  https://mailarchive.ietf.org/arch/msg/spring/nX5-1rdXKOw6ks73VYfwvn7iaI8
Darren Dukes  https://mailarchive.ietf.org/arch/msg/spring/v8UAgBGQ0yp0VBwGkZ3RwzH1MME

Thanks
dan

---

From: "qinfengwei" <[email-masked]>
Date: Fri, 15 May 2020 18:24:23 +0800

Chairs,

There are indeed many problems unclarified in the CRH solution and I think it is too early to talk of adoption. 
As a operator, there many points of great concern, such as the low forwarding efficiency, security issue, etc, required further clarification.

Thanks,
Fengwei Qin

-----邮件原件-----
发件人: ipv6 [mailto:[email-masked]] 代表 Voyer, Daniel
发送时间: 2020年5月14日 22:51
收件人: Bob Hinden; John Scudder
抄送: [email-masked]; [email-masked]
主题: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Chairs,

Thanks
dan

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 15 May 2020 12:53:56 +0000

Hi John,

You’ll recall what the 6man chairs said in Montreal and Singapore regarding CRH:

During Spring session [1]:  
“[Bob Hinden]  As 6man co-chair, would like to understand whether SPRING is interested in this work.”

Bob reiterated the same message during Singapore IETF [https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/]
“Regarding the Spring related drafts … <snip> We did not see very much value in also discussing them in 6man.   Once items have been adopted in Spring, we think it is appropriate to adopt the IPv6 relevant parts, but that’s not yet the case now.”

Nothing has changed w.r.t. the competing solution review in Spring since Singapore.

Instead of following the chair’s direction, in Feb 2020 the authors of CRH just simply removed normative reference to the SRm6 to get 6man adopt CRH ahead of SPRING compression discussion..

To achieve the said goal, the authors of CRH draft first positioned it as a replacement of RH0.
Now RH0 has been removed from CRH draft.
There is no longer any architecture and use-case to justify adoption call for CRH.

It is clear to all that the current draft and adoption request is an attempt to circumvent the standard practice.

Ref:
[1] https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00
Video: Under: Ron’s session on IPv6 Support for Segment Routing: SRv6+       (10:44)

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of John Scudder <jgs=[email-masked]>
Date: Wednesday, May 13, 2020 at 4:02 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Ron: Can I ask on list?

Bob: OK.

Thanks,

—John

[1] https://cuberule.com

---

From: Andrew Alston <[email-masked]>
Date: Fri, 15 May 2020 13:15:05 +0000

Zafar,

Let me give another perspective on this.

In Montreal – people screamed – no use case – a use case was provided – and for months after – people kept screaming – no use case – until they couldn’t scream it anymore because the mails showed clearly that use cases had been supplied
Then – we moved onto the “We need an architecture” – and you yourself misquoted a participant in 6man claiming they demanded an architecture – when they clearly didn’t – see the interim meeting minutes – and when it was claimed that this is a building block –
It became – omg its an rh0 replacement – and pick on that aspect of it.

(Those last 2 might be in different orders)

Then – there was this bizarre claim that a vendor “wanted” something despite the fact that they hadn’t said it.

What I can say is – rather that come with technical arguments against it – what I am seeing is smoke and mirrors – pulling things out of thing air – twisting words – trying to mis-portray things – and the only reason for that is – because there are no solid technical arguments against it.  I am SHOCKED that more people cannot see the smoke and mirrors and twisting of words going on here.

Because from my perspective – when someone runs out of ideas – they start making things up out of thin air – one after another – please – see my earlier email about obstruction and how its not helping any of us.

Lets debate the document on technical merits – what are your direct technical arguments against this – or are we continue to continue with misdirection?

Andrew

From: ipv6 <[email-masked]> On Behalf Of Zafar Ali (zali)
Sent: Friday, 15 May 2020 15:54
To: John Scudder <jgs=[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Hi John,

Bob reiterated the same message during Singapore IETF [https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/<https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/>]
“Regarding the Spring related drafts … <snip> We did not see very much value in also discussing them in 6man.   Once items have been adopted in Spring, we think it is appropriate to adopt the IPv6 relevant parts, but that’s not yet the case now.”

Ref:
[1] https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00<https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00>
Video: Under: Ron’s session on IPv6 Support for Segment Routing: SRv6+       (10:44)

Thanks

Regards … Zafar

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of John Scudder <jgs=[email-masked]<mailto:jgs=[email-masked]>>
Date: Wednesday, May 13, 2020 at 4:02 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Ron: Can I ask on list?

Bob: OK.

Thanks,

—John

[1] https://cuberule.com<https://cuberule.com>
--------------------------------------------------------------------
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: Tom Herbert <[email-masked]>
Date: Fri, 15 May 2020 08:20:08 -0700

On Wed, May 13, 2020 at 1:12 PM Robert Raszuk <[email-masked]> wrote:
> 6man just standardized SRH. Why SRH content can not be filled by controller and used for the very same purpose as authors intend to use CRH for ?
>
> Oh one may say there is no compression there ... If so I recommend to take a look at uSID and vSID proposals.
>

Robert,

Thanks for the pointer. Comparing vSID and CRH, it's pretty obvious
that vSID is more flexible, however it is also signficantly more
complex in allowing different variable length SID within the same
packet. The question is whether the complexity of vSID is justified
and will it lead to feasible implementation? Considering that routing
headers will often be processed in the fast path, I believe the answer
tends to be "no" for these sort of things. History has taught us that
when it come to defining network headers, simpler is better for
efficiency, feasibility, and inter-operability. This is precisely why
I like CRH header, it is an incredibly simple format and doesn't
contain a bunch of fields like flags, tags, TLVs, or variable length
SIDs that the WG would need to spend a lot of time on defining to be
correct, but would probably never be used in the real world. I believe
CRH will be a necessary and sufficient protocol format for the
problem.

Tom

> Is it in good interest of anyone deploying segment routing to have to deal with N different non interoperable headers ? Does it make anyone's life easier ?
>
> Kind regards,
> Robert.
>
> PS. So my own side observation lead me to believe it is not about "too early to ask for adoption" ... it is actually "way too late"
>
> On Wed, May 13, 2020 at 10:01 PM John Scudder <jgs=[email-masked]> wrote:
>>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 15 May 2020 15:53:15 +0000

Fengwei,

I would be glad to address your concern regarding CRH forwarding efficiency by demonstrating our ASIC-based implementation. Please contact me off-line to set up the demo.

                                                                                                            Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of qinfengwei
Sent: Friday, May 15, 2020 6:24 AM
To: 'Voyer, Daniel' <[email-masked]>; 'Bob Hinden' <[email-masked]>; John Scudder <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: 答复: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Chairs,

Thanks,
Fengwei Qin

-----邮件原件-----
发件人: ipv6 [mailto:[email-masked]] 代表 Voyer, Daniel
发送时间: 2020年5月14日 22:51
收件人: Bob Hinden; John Scudder
抄送: [email-masked]; [email-masked]
主题: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Chairs,

Robert Raszuk on the many extensions required by CRH (IGP, BGP, OAM) https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE__;!!NEt6yMaO-gk!Rsq5IevffxDGzSaubsxUQGEp3Z20w4iQgtAr5W2DIllqh8ATorw6BmI9AZ9Oi13y$
Robert Raszuk and Dirk Steinberg on CRH being a poor re-engineering of SR-MPLS over IP/UDP
Robert: https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo__;!!NEt6yMaO-gk!Rsq5IevffxDGzSaubsxUQGEp3Z20w4iQgtAr5W2DIllqh8ATorw6BmI9AXGHkPxd$
Dirk: https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM__;!!NEt6yMaO-gk!Rsq5IevffxDGzSaubsxUQGEp3Z20w4iQgtAr5W2DIllqh8ATorw6BmI9AR7Bwfco$
Dan Voyer reminding that SRv6 is a mature technology (deployments, long IETF work), as opposed to CRH https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4__;!!NEt6yMaO-gk!Rsq5IevffxDGzSaubsxUQGEp3Z20w4iQgtAr5W2DIllqh8ATorw6BmI9Aa-nYZoe$
Zhibo Hu on the many advantages of SRv6 https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ__;!!NEt6yMaO-gk!Rsq5IevffxDGzSaubsxUQGEp3Z20w4iQgtAr5W2DIllqh8ATorw6BmI9AaEsNtpi$
Cheng Li expressing concerns on the dataplane performance of CRH https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/XK0F40oEuZv-3ule-X5685d_6Mc__;!!NEt6yMaO-gk!Rsq5IevffxDGzSaubsxUQGEp3Z20w4iQgtAr5W2DIllqh8ATorw6BmI9AVom_igs$
Zafar summarizing the main issues of CRH https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4__;!!NEt6yMaO-gk!Rsq5IevffxDGzSaubsxUQGEp3Z20w4iQgtAr5W2DIllqh8ATorw6BmI9AclkAHrx$
Wim Henderickx  https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/nX5-1rdXKOw6ks73VYfwvn7iaI8__;!!NEt6yMaO-gk!Rsq5IevffxDGzSaubsxUQGEp3Z20w4iQgtAr5W2DIllqh8ATorw6BmI9AVwEXBTN$
Darren Dukes  https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/v8UAgBGQ0yp0VBwGkZ3RwzH1MME__;!!NEt6yMaO-gk!Rsq5IevffxDGzSaubsxUQGEp3Z20w4iQgtAr5W2DIllqh8ATorw6BmI9AYizODU6$

Thanks
dan

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

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

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 15 May 2020 17:21:06 +0100

Zafar Ali (zali) wrote on 15/05/2020 13:53:
> It is clear to all that the current draft and adoption request is an 
> attempt to circumvent the standard practice.

Zafar,

Speaking as an unaffiliated operator who runs kit from plenty of 
vendors, CRH looks interesting from a technical point of view.

Juniper seems to be claiming running code, so it would be a more 
productive use of working group time if we concentrated on rough 
consensus on the technical merits rather than getting side-tracked with 
procedural distractions.

Nick

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 15 May 2020 16:43:28 +0000

Hi Andrew,

Now that you mentioned you are “SHOCKED that more people cannot see the smoke and mirrors” …
let me remind everyone.

CRH work is to propose an alternative encapsulation in SPRING against SRH.
There are several SRH/SRv6 net pgm compliant compression techniques that are far better than CRH proposal (in efficiency) and that requires no SRH change and no SRv6 CP change [list-of-competing-solutions].

It appears, not able to defend against that argument, the authors took a strange path:

  *   Launched a political attack against the SPRING chairs and AD via calls for resignation and subsequent appeals resulting in derailing work in SPRING, including all work on compression (of which SRm6 was one option).
  *   Removed all reference to SRm6 from this CRH document.
  *   Attempted to get 6man to adopt CRH ahead of SPRING resuming its work on compression.

Yes, people can see the smoke and mirrors.

Ref: List of competing solutions in SPRING
[1] https://datatracker.ietf.org/doc/draft-cl-spring-generalized-srv6-np/?include_text=1
[2] https://datatracker.ietf.org/doc/draft-li-spring-compressed-srv6-np/?include_text=1
[3] https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/?include_text=1
[4] https://datatracker.ietf.org/doc/draft-decraene-spring-srv6-vlsid/
[5] https://datatracker.ietf.org/doc/draft-filsfils-spring-net-pgm-extension-srv6-usid/?include_text=1

Thanks

Regards … Zafar

From: Andrew Alston <[email-masked]>
Date: Friday, May 15, 2020 at 9:15 AM
To: "Zafar Ali (zali)" <[email-masked]>, John Scudder <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Zafar,

Andrew

Hi John,

Ref:

Thanks

Regards … Zafar

Ron: Can I ask on list?

Bob: OK.

Thanks,

—John

[1] https://cuberule.com

---

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

Hi Nick,

> CRH looks interesting from a technical point of view.

Can you enumerate what you find interesting in it ?

For me the fundamental drawback of MPLS or SR-MPLS is requirement mapping.
CRH falls in the same bucket - requires yet one more mapping abstraction.

I have proven with the referenced IP-TE + NP document that you can do path
engineering without any mapping. In fact even without any change to IPv6
protocol.

So what are those technical merits - 16 or 32 bit SIDs ? One size fit all
again ? What is the delta against SR-MPLS technically speaking ? Note that
nothing prevents you to run MPLS over IP if that is the issue.

Best,
R.

On Fri, May 15, 2020 at 6:21 PM Nick Hilliard <[email-masked]> wrote:

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

---

From: John Scudder <[email-masked]>
Date: Fri, 15 May 2020 18:56:30 +0000

There are a number of messages following this same “CRH is really SR and SR is not 6man’s business” template; I’ll reply to just Zafar’s but I think the overall point applies to all of them. (The overall point can be summed up as “no, it isn’t really SR”.)

SRm6 was (and is, for that matter) a proposed Segment Routing technology. The proper place for its discussion is in SPRING. What Ron tells us is that subsequent to drafting of SRm6, he realized that the underlying encapsulation technique has useful application independent of SRm6 or SR in general. This should be completely unsurprising to people versed in SR; after all, SR is one particular architecture applied on top of MPLS and IPv6, and absolutely nobody is asserting those technologies are actually SR.

There's a long history both within and outside the IETF of a technology being initially pursued for one reason, and then extended or even completely repurposed into another. This is the essence of invention. The example nearest and dearest to my heart is BGP of course. It was invented as a humble Internet routing protocol, but it’s now used for quite a number of different things (and let’s please not rathole on whether that’s a good thing or a bad thing, eh?). To take another example entirely outside the IETF domain, Teflon was discovered by a DuPont chemist trying to develop a new refrigerant. [1] I don’t think anyone thinks Teflon is worthless because it’s not being used as a refrigerant. That kind of argument is equally fallacious with respect to CRH.

As for "It is clear to all that the current draft and adoption request is an attempt to circumvent the standard practice”, do you really want to go there? First of all, it’s not clear to all: I’m a member of the class “all”, this is not clear to me, Q.E.D. the assertion is false. There’s another example, quite recently, of discussion in this group where it was asserted that someone was “obviously” acting in bad faith; I’m referring to the novel interpretation of what “destination” means in RFC 8200. In the end this was resolved (roughly resolved anyway) by one camp stating, hand on heart, that they sincerely believe their reading is accurate, and the others accepting — or at least accepting that they can’t refute — that statement. Unless you have a way of seeing into another person’s soul to know their intentions, I think you have no business charging bad faith, and I find it somewhat tedious.

As others have mentioned, I think it would be much more productive, not to mention less unpleasant, for the WG to focus on the technical merits of the proposal.

—John

[1] https://en.wikipedia.org/wiki/Polytetrafluoroethylene

On May 15, 2020, at 8:53 AM, Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>> wrote:

Hi John,

Ref:
[1] https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00<https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00__;!!NEt6yMaO-gk!QbAHSQ3t9Po0n90FQqYbHv8VOpFpwcb739Wzojg7KC2emCeE6TroAjlIlCFOvg$>
Video: Under: Ron’s session on IPv6 Support for Segment Routing: SRv6+       (10:44)

Thanks

Regards … Zafar

Ron: Can I ask on list?

Bob: OK.

Thanks,

—John

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 May 2020 16:40:29 -0300

Zafar,

I will be very open and straightforward:

* I don't care myself about CRH. i.e., I'm not pushing that effort 
forward, and have no kind of agenda whatsoever around it.

* Your claims are attacking myself, because you seem to imply that the 
appeal was intended as a political attack against the spring chairs or 
responsible AD, or to benefit other work such as CRH.

In that light, I'm going to be quite open and transparent:

1) I asked numerous times for the Spring chairs and responsible AD to 
become involved, so that I wouldn't have to formally appeal the spring 
process. I did it multiple times, both on-list and off-list -- I even 
did so on the [email-masked] mailing-list, and well before spring wglc 
consensus was declared. Other people (please see the references in the 
appeal text) did the same. But the chairs and AD dismissed our concerns, 
and went ahead.

2) I made it public, numerous times, that I would Appeal the decision. 
That was even reflected in the document shepherd's writeup for the 
network-programming draft.

3) I have been the one that wrote 100% of the text in the Appeal. Not 
99%, but 100%. In the process, I asked quite-publicly, on-list, that 
folks send me the issues that they had raised and felt that had been 
dismissed, such that the Appeal would be as complete and well-documented 
as possible.

I had the Appeal text ready a week or so after Spring WGLC consensus was 
declared, but had to wait to submit it because it took the Spring chairs 
over a month to reflect their decision on the datatracker.

In the mean time, I contacted many 6man participants, and sent them my 
draft version of the appeal, asking if they had any comments or corrections.

I was planning to submit the Appeal alone. But while doing the last pass 
on the appeal text, I happened to talk to Andrew and Sander (Appeal 
co-signers) about the issue of the IPv6 address space involved. And 
during that last exchange, they expressed that they would like to sign 
the appeal (noting that it was up to me).

I agreed with them to sign the Appeal, in the same way that I would have 
agreed with any other participant signing the Appeal if they agreed with 
the points being raised by the Appeal.

4) It is not my business whether folks (say, CRH authors or whoever), 
benefit from the Appeal. Because my motivation for submitting the Appeal 
has been my technical concerns with the network-programming draft, and 
with the lack of transparency (at best) of the procedures that led to 
Spring shipping that document to the IESG. Other times I had experienced 
other arbitrary decisions, and experience has shown that silently 
accepting those turns out to be a bigger problem over time, and they 
kind of become established practice. So this time it was "enough is 
enough" for me.

So, as far as the Appeal is concerned, I hope you can rectify your 
statements, because they are, at best, defamatory and unfounded.

Thanks,
Fernando

On 15/5/20 13:43, Zafar Ali (zali) wrote:
> There are several SRH/SRv6 net pgm compliant compression techniques that 
> are far better than CRH proposal (in efficiency) and that requires no 
> SRH change and no SRv6 CP change [list-of-competing-solutions].
> 
>   * Launched a political attack against the SPRING chairs and AD via
>     calls for resignation and subsequent appeals resulting in derailing
>     work in SPRING, including all work on compression (of which SRm6 was
>     one option).
> *Ref: List of competing solutions in SPRING*
> 
> [1] 
> https://datatracker.ietf.org/doc/draft-cl-spring-generalized-srv6-np/?include_text=1 
> 
> 
> [2] 
> https://datatracker.ietf.org/doc/draft-li-spring-compressed-srv6-np/?include_text=1 
> 
> 
> [3] 
> https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/?include_text=1 
> 
> 
> [5] 
> https://datatracker.ietf.org/doc/draft-filsfils-spring-net-pgm-extension-srv6-usid/?include_text=1 
> 
> 
> Thanks
> 
> Regards … Zafar
> 
> *From: *Andrew Alston <[email-masked]>
> *Date: *Friday, May 15, 2020 at 9:15 AM
> *To: *"Zafar Ali (zali)" <[email-masked]>, John Scudder 
> <[email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: Adoption call criteria for CRH? [was: Re: CRH and RH0]
> 
> Zafar,
> 
> In Montreal – people screamed – no use case – a use case was provided – 
> and for months after – people kept screaming – no use case – until they 
> couldn’t scream it anymore because the mails showed clearly that use 
> cases had been supplied
> 
> Then – we moved onto the “We need an architecture” – and you yourself 
> misquoted a participant in 6man claiming they demanded an architecture – 
> when they clearly didn’t – see the interim meeting minutes – and when it 
> was claimed that this is a building block –
> 
> Then – there was this bizarre claim that a vendor “wanted” something 
> despite the fact that they hadn’t said it.
> 
> What I can say is – rather that come with technical arguments against it 
> – what I am seeing is smoke and mirrors – pulling things out of thing 
> air – twisting words – trying to mis-portray things – and the only 
> reason for that is – because there are no solid technical arguments 
> against it.  I am SHOCKED that more people cannot see the smoke and 
> mirrors and twisting of words going on here.
> 
> Because from my perspective – when someone runs out of ideas – they 
> start making things up out of thin air – one after another – please – 
> see my earlier email about obstruction and how its not helping any of us.
> 
> Lets debate the document on technical merits – what are your direct 
> technical arguments against this – or are we continue to continue with 
> misdirection?
> 
> Andrew
> 
> *From:* ipv6 <[email-masked]> *On Behalf Of *Zafar Ali (zali)
> *Sent:* Friday, 15 May 2020 15:54
> *To:* John Scudder <jgs=[email-masked]>; [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]
> 
> Hi John,
> 
> Bob reiterated the same message during Singapore IETF 
> [https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/]
> 
> “Regarding the Spring related drafts … <snip> We did not see very much 
> value in also discussing them in 6man.   Once items have been adopted in 
> Spring, we think it is appropriate to adopt the IPv6 relevant parts, but 
> that’s not yet the case now.”
> 
> Instead of following the chair’s direction, in Feb 2020 the authors of 
> CRH just simply removed normative reference to the SRm6 to get 6man 
> adopt CRH ahead of SPRING compression discussion..
> 
> *From: *ipv6 <[email-masked] <mailto:[email-masked]>> on 
> behalf of John Scudder <jgs=[email-masked] 
> <mailto:jgs=[email-masked]>>
> *Date: *Wednesday, May 13, 2020 at 4:02 PM
> *To: *"[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *Subject: *Adoption call criteria for CRH? [was: Re: CRH and RH0]
> 
> long(ish) message, and can be summarized as (1) does 6man require 
> consent from SPRING before defining routing headers, and (2) what 
> criteria are the chairs using to decide when an adoption call is OK?
> 
> It seems to me there are at least two, only vaguely related, 
> conversations going on. One of them is a debate about the assertion that 
> 6man can’t even consider taking up CRH unless SPRING approves it. The 
> other is a more free-wheeling line of questioning about “what is CRH for 
> anyway”?
> 
> recollection. Anyway, I don’t think I’ve seen this answered on list yet, 
> so I’m asking again.
> 
> I have quite a bit of history with how SPRING was chartered; I was one 
> of the original co-chairs and helped write the charter, god help me. I 
> can tell you for certain there was no intent that SPRING should have 
> exclusive ownership of source routing in the IETF, the name isn’t a 
> power-grab, it’s a clever backronym, as we do in the IETF. If one entity 
> in the IETF were to take charge of all source routing, that sounds more 
> like a new area than a WG. But don’t take my word for it, go read the 
> various iterations of the charter. As anyone who’s looked at the Segment 
> Routing document set can tell, Segment Routing is one, very specific, 
> way of doing source routing. As Ketan and others have pointed out, it’s 
> a pile of architecture plus the bits and pieces to instantiate that 
> architecture. That is fine, but the idea that merely because a 
> technology might be used to instantiate part of that architecture, it’s 
> owned by SPRING, is overreach. Just because a sandwich is a filling 
> between two pieces of starch, doesn’t mean every filling between two 
> pieces of starch is a sandwich. [1]
> 
> permission from SPRING for all routing headers, or just some, and if 
> it’s just some, what characterizes them?
> 
> [email-masked] <mailto:[email-masked]>
> 

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 15 May 2020 13:20:15 -0700

Hi Zafar,
thank you for referring to the proposal that I'm one of the co-authors
(Unified SID). And I cannot agree more that it is time for SPRING to take
on the discussion of shorter SID in Segment Routing over IPv6. I think that
the first step that all interested in the subject can easily do is to share
their comments on the draft that explains the use cases for shorter SIDs in
SR over IPv6
<https://datatracker.ietf.org/doc/draft-cheng-shorter-srv6-sid-requirement/>.
(And we don't need an interim meeting to have such discussion, simply read
and share comments on the mailing list.) Then adopting the document that
will incorporate suggestions and address comments, in my opinion, will be a
clear indication of SPRING WG interest to work on a technical solution of
shorter SIDs in SR over IPv6 data plane.

Regards,
Greg

On Fri, May 15, 2020 at 9:43 AM Zafar Ali (zali) <zali=
[email-masked]> wrote:

> are far better than CRH proposal (in efficiency) and that requires no SRH
> change and no SRv6 CP change [list-of-competing-solutions].
>
>
>
>    - Launched a political attack against the SPRING chairs and AD via
>    calls for resignation and subsequent appeals resulting in derailing work in
>    SPRING, including all work on compression (of which SRm6 was one option).
>    - Removed all reference to SRm6 from this CRH document.
>    - Attempted to get 6man to adopt CRH ahead of SPRING resuming its work
>    on compression.
>
>
>
> *To: *"Zafar Ali (zali)" <[email-masked]>, John Scudder <[email-masked]>,
> "[email-masked]" <[email-masked]>
> couldn’t scream it anymore because the mails showed clearly that use cases
> had been supplied
>
> What I can say is – rather that come with technical arguments against it –
> what I am seeing is smoke and mirrors – pulling things out of thing air –
> twisting words – trying to mis-portray things – and the only reason for
> that is – because there are no solid technical arguments against it.  I am
> SHOCKED that more people cannot see the smoke and mirrors and twisting of
> words going on here.
>
>
>
> Because from my perspective – when someone runs out of ideas – they start
> making things up out of thin air – one after another – please – see my
> earlier email about obstruction and how its not helping any of us.
>
>
>
> Bob reiterated the same message during Singapore IETF [
> https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/]
>
> Instead of following the chair’s direction, in Feb 2020 the authors of CRH
> just simply removed normative reference to the SRm6 to get 6man adopt CRH
> ahead of SPRING compression discussion..
>
>
>
> https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00
>
> *From: *ipv6 <[email-masked]> on behalf of John Scudder <
> jgs=[email-masked]>
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 15 May 2020 21:47:29 +0000

Hi John,

Re: I think it would be much more productive, not to mention less unpleasant, for the WG to focus on the technical merits of the proposal.

Here is a partial list of issues.

Robert "Drawback of Mapping table"
https://mailarchive.ietf.org/arch/msg/ipv6/g2vrwFO-cjYX0ZeiMxqjWNGfkUU/

Ketan: "All segment types used are as defined in SR architecture RFC8402 (read poor man's job to distance from SRm6)"
https://mailarchive.ietf.org/arch/msg/ipv6/5jDdun2yzwnsJtJE1PzVvj1bjjQ/

Fengwei Qin: "security concerns"
https://mailarchive.ietf.org/arch/msg/ipv6/Vzcojf2mFXdrqW5OYoXf8iwNatQ/

Jingrong: "Limited domain scope and security concerns"
https://mailarchive.ietf.org/arch/msg/ipv6/QyaRQAjPoRExJGWLXaSXWHcMDdQ/

Robert: "How other functions like TI-LFA, uloop avoidance are performed"
https://mailarchive.ietf.org/arch/msg/ipv6/7_aEF5M6owrIqb3t3BNFdCSZ3jM/

Darren: "use-case beyond SRm6"
https://mailarchive.ietf.org/arch/msg/ipv6/emQ3Sj_l4fWXErZY_nhQAbYxr5Y/

Robert: "need for CRH-FIB on all nodes"
https://mailarchive.ietf.org/arch/msg/ipv6/IXlGxvjBBKvTMTA12UaX8jHqQNw/

Shuping: "How to support VPN and HW inefficiency for VPN in DOH and segments in RH."
https://mailarchive.ietf.org/arch/msg/ipv6/aO0MdyDZci2k58cV0W0gzoa1o-c/

Ketan: "Need for clarification for CRH "standalone" proposal"
"https://mailarchive.ietf.org/arch/msg/ipv6/rCZ0HcH009qq4uW4m5VxkT5twNg/"

Robert: "operation complexity"
https://mailarchive.ietf.org/arch/msg/ipv6/LGnbYIv6B4ZoEKrsGp4RHRyO1pA/

Zafar "how to debug the mapping table entry"
During 6man interim session

Darren "clarification for "standalone" CRH architecture use"
https://mailarchive.ietf.org/arch/msg/ipv6/L8kVLCuxNBptiI2cONI32U8jjGM/

Ketan: "CRH is not source routing of RFC791 (use of adj SID and prefix SID RFC8402)"
https://mailarchive.ietf.org/arch/msg/ipv6/Xli0zIUZa53nSbBniOdiRviToqM/

Dan V provided the following list of open issues.

Thanks

Regards … Zafar

From: John Scudder <[email-masked]>
Date: Friday, May 15, 2020 at 2:56 PM
To: "Zafar Ali (zali)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

—John

Hi John,

Ref:
[1] https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00__;!!NEt6yMaO-gk!QbAHSQ3t9Po0n90FQqYbHv8VOpFpwcb739Wzojg7KC2emCeE6TroAjlIlCFOvg$>
Video: Under: Ron’s session on IPv6 Support for Segment Routing: SRv6+       (10:44)

Thanks

Regards … Zafar

Ron: Can I ask on list?

Bob: OK.

Thanks,

—John

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

---

From: John Scudder <[email-masked]>
Date: Fri, 15 May 2020 21:58:34 +0000

Zafar,

I’m not sure what contribution you believe is made by this selective compilation of messages. We all know how to use the mailing list archives.

—John

On May 15, 2020, at 5:47 PM, Zafar Ali (zali) <[email-masked]> wrote:

Hi John,

Robert "Drawback of Mapping table"
https://mailarchive.ietf.org/arch/msg/ipv6/g2vrwFO-cjYX0ZeiMxqjWNGfkUU/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/g2vrwFO-cjYX0ZeiMxqjWNGfkUU/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RHdgMKfPA$>

Ketan: "All segment types used are as defined in SR architecture RFC8402 (read poor man's job to distance from SRm6)"
https://mailarchive.ietf.org/arch/msg/ipv6/5jDdun2yzwnsJtJE1PzVvj1bjjQ/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/5jDdun2yzwnsJtJE1PzVvj1bjjQ/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5REnnlJ1ng$>

Fengwei Qin: "security concerns"
https://mailarchive.ietf.org/arch/msg/ipv6/Vzcojf2mFXdrqW5OYoXf8iwNatQ/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/Vzcojf2mFXdrqW5OYoXf8iwNatQ/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RH9OzBvZA$>

Jingrong: "Limited domain scope and security concerns"
https://mailarchive.ietf.org/arch/msg/ipv6/QyaRQAjPoRExJGWLXaSXWHcMDdQ/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/QyaRQAjPoRExJGWLXaSXWHcMDdQ/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RFcQ-L6Bw$>

Robert: "How other functions like TI-LFA, uloop avoidance are performed"
https://mailarchive.ietf.org/arch/msg/ipv6/7_aEF5M6owrIqb3t3BNFdCSZ3jM/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/7_aEF5M6owrIqb3t3BNFdCSZ3jM/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RHfz5gmvQ$>

Darren: "use-case beyond SRm6"
https://mailarchive.ietf.org/arch/msg/ipv6/emQ3Sj_l4fWXErZY_nhQAbYxr5Y/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/emQ3Sj_l4fWXErZY_nhQAbYxr5Y/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RFIauPVrQ$>

Robert: "need for CRH-FIB on all nodes"
https://mailarchive.ietf.org/arch/msg/ipv6/IXlGxvjBBKvTMTA12UaX8jHqQNw/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/IXlGxvjBBKvTMTA12UaX8jHqQNw/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RFs5BuzUA$>

Shuping: "How to support VPN and HW inefficiency for VPN in DOH and segments in RH."
https://mailarchive.ietf.org/arch/msg/ipv6/aO0MdyDZci2k58cV0W0gzoa1o-c/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/aO0MdyDZci2k58cV0W0gzoa1o-c/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5REBQ8WLdA$>

Ketan: "Need for clarification for CRH "standalone" proposal"
"https://mailarchive.ietf.org/arch/msg/ipv6/rCZ0HcH009qq4uW4m5VxkT5twNg/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/rCZ0HcH009qq4uW4m5VxkT5twNg/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RE-hISLpA$>"

Robert: "operation complexity"
https://mailarchive.ietf.org/arch/msg/ipv6/LGnbYIv6B4ZoEKrsGp4RHRyO1pA/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/LGnbYIv6B4ZoEKrsGp4RHRyO1pA/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RGo9QRo7g$>

Darren "clarification for "standalone" CRH architecture use"
https://mailarchive.ietf.org/arch/msg/ipv6/L8kVLCuxNBptiI2cONI32U8jjGM/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/L8kVLCuxNBptiI2cONI32U8jjGM/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5REcxU6s0w$>

Ketan: "CRH is not source routing of RFC791 (use of adj SID and prefix SID RFC8402)"
https://mailarchive.ietf.org/arch/msg/ipv6/Xli0zIUZa53nSbBniOdiRviToqM/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/Xli0zIUZa53nSbBniOdiRviToqM/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RGu1rEFPw$>

Robert Raszuk on the many extensions required by CRH (IGP, BGP, OAM) https://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RHUgmLaow$>
Robert Raszuk and Dirk Steinberg on CRH being a poor re-engineering of SR-MPLS over IP/UDP
Robert: https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RFZK8SL8g$>
Dirk: https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RFrPpTa2Q$>
Dan Voyer reminding that SRv6 is a mature technology (deployments, long IETF work), as opposed to CRH https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RHe_vtDZw$>
Zhibo Hu on the many advantages of SRv6 https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5REwsZu_yg$>
Cheng Li expressing concerns on the dataplane performance of CRH https://mailarchive.ietf.org/arch/msg/spring/XK0F40oEuZv-3ule-X5685d_6Mc<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/XK0F40oEuZv-3ule-X5685d_6Mc__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RGv8RCBGg$>
Zafar summarizing the main issues of CRH https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RFgRYpz0w$>
Wim Henderickx  https://mailarchive.ietf.org/arch/msg/spring/nX5-1rdXKOw6ks73VYfwvn7iaI8<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/nX5-1rdXKOw6ks73VYfwvn7iaI8__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RHKQ_PKkw$>
Darren Dukes  https://mailarchive.ietf.org/arch/msg/spring/v8UAgBGQ0yp0VBwGkZ3RwzH1MME<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/v8UAgBGQ0yp0VBwGkZ3RwzH1MME__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RHd5OPPxg$>

Thanks

Regards … Zafar

—John

[1] https://en.wikipedia.org/wiki/Polytetrafluoroethylene<https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Polytetrafluoroethylene__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RFrCFVvXA$>

Hi John,

Bob reiterated the same message during Singapore IETF [https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RG3IYxxSQ$>]
“Regarding the Spring related drafts … <snip> We did not see very much value in also discussing them in 6man.   Once items have been adopted in Spring, we think it is appropriate to adopt the IPv6 relevant parts, but that’s not yet the case now.”

Ref:

Thanks

Regards … Zafar

Ron: Can I ask on list?

Bob: OK.

Thanks,

—John

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 May 2020 07:24:56 -0700

On Wed, May 13, 2020 at 1:12 PM Robert Raszuk <[email-masked]> wrote:
> 6man just standardized SRH. Why SRH content can not be filled by
controller and used for the very same purpose as authors intend to use CRH
for ?
> Oh one may say there is no compression there ... If so I recommend to
take a look at uSID and vSID proposals.
Hi Robert,

I took a look at these proposals. It's very obvious that the format of CRH
is significantly simpler than either of these and is simpler than SRH as
well. Complexity in protocol format correlates to how amenable the protocol
is to feaible implementation (in HW and SW), how well it can be secured,
and how efficient in terms of wire overhead and processing overhead.

It is interesting to note that figure Figure 3 in
draft-decraene-spring-srv6-vlsid-03 would be identical to Figure 1 in
draft-bonica-6man-comp-rtg-hdr-22 if the Last Entry, Flags, Tag, and TLVs
fields were removed. Since these fields aren't used in the common case,
they are easily compressed by simply removing them. So the material
difference between the formats is how the length of SIDs is determined. In
CRH this is explicit in the routing type, there is one type for 16-bit SID
format and one type for 32-bit format. AFAICT in vSID the SID length is
more like a negotiated parameter that per destination address that uses the
same routing type as SRH. While the vSID method might be more flexible and
allow arbitrary SID lengths, it leads to more complexity since the routing
header can no longer be parsed without external information. For instance,
if a management device snoops packets in the path it wouldn't be able to
parse the SID list without participating in the protocol that distributes
the length information. Similarly, if a legacy SRH receiver receives a vSID
header it seems like it would parse it incorrectly.

In any case, I don't see why the vSID and CRH proposals couldn't be unified
or why SR wouldn't be able to use CRH to convey compressed SIDs.

Tom

> Is it in good interest of anyone deploying segment routing to have to
deal with N different non interoperable headers ? Does it make anyone's
life easier ?
conversations going on. One of them is a debate about the assertion that
6man can’t even consider taking up CRH unless SPRING approves it. The other
is a more free-wheeling line of questioning about “what is CRH for anyway”?
>> I have quite a bit of history with how SPRING was chartered; I was one
of the original co-chairs and helped write the charter, god help me. I can

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 18 May 2020 16:42:00 +0200

Hi Tom,

Well what I do not like about CRH is this:

*A* Requirement for mapping of SIDs to IPv6 addresses - see the header may
look simple in the draft as the does not talk about mapping. Handwaving of
config by hand or controller I do not buy.

*B* Two size will not fit all. Maybe if there is CRH type and we have 8,12,
16,24,32 bit SIDs it could be optimal for most deployments

*C* No mention what happens when node in the SID list is down ... modern
networks do not tolerate outages required to signal all the way to the
ingress to redo computation and start repair from there. This is BAD
NETWORK DESIGN.

*D* Separation of destination actions into Destination Options Header. For
some it may be a plus - for me this is minus.

*E* Unlike say SRH RFC this draft does not even mention once that to impose
CRH packets should be encapsulated.

Thx,
R.

On Mon, May 18, 2020 at 4:26 PM Tom Herbert <[email-masked]> wrote:

> In any case, I don't see why the vSID and CRH proposals couldn't be
> unified or why SR wouldn't be able to use CRH to convey compressed SIDs.
>
> Tom
>
> >> But at any rate, the question for the chairs is: do you think 6man
> needs SPRING’s permission in order to consider adopting CRH? Does 6man need
> >> This seems to me to be exactly the kind of discussion one would
> normally have in the context of an adoption call. Why is it not being had
> in that context? To rewind back to the interim, if it’s still “too early
> for adoption call”, what has to happen for it not to be too early?
> >>
> >> Thanks,
> >>
> >> —John
> >>
> >> [1] https://cuberule.com

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 May 2020 07:37:45 +1000

On Tue, 19 May 2020 at 00:42, Robert Raszuk <[email-masked]> wrote:
> *A* Requirement for mapping of SIDs to IPv6 addresses - see the header may look simple in the draft as the does not talk about mapping. Handwaving of config by hand or controller I do not buy.
>

What is wrong with mapping?

> *B* Two size will not fit all. Maybe if there is CRH type and we have 8,12, 16,24,32 bit SIDs it could be optimal for most deployments
>

Variable length identifiers in the forwarding plane has been tried
multiple times in the past and abandoned. See RFD 675, Internet
Engineering Note 21, etc.

"There had been debates during the 1976
year about address size and proposals ranged from 32 to 128 bit to
variable length address structures. No convergence appeared and, as the
program manager at DARPA, I felt it necessary to simply declare a
choice. At the time (1977), it seemed to me wasteful to select 128 bits
and variable length address structures led to a lot of processing
overhead per packet to find the various fields of the IP packet format.
So I chose 32 bits." - Vint Cerf -
https://mailman.nanog.org/pipermail/nanog/2010-April/020488.html

I would prefer CR had a singe size of 24 bits, as that would seem to
me to be the Goldilocks size for local network use (16 million
values), and per RFC 5505, "Anything that can be configured can be
misconfigured.".

However I don't know enough about ASICs to judge whether or not 24
bits could be acceptably accommodated for all cases, so I accept 2
sizes, 16 and 32 bits.

> *C* No mention what happens when node in the SID list is down ... modern networks do not tolerate outages required to signal all the way to the ingress to redo computation and start repair from there. This is BAD NETWORK DESIGN.
>

This problem exists with any source routing, and has existed for many
decades in IPv6, IPv4, MPLS and Token Ring source routing. ICMPv6,
routing protocol signalling, BFD, etc. are all existing solutions to
this problem.

> *D* Separation of destination actions into Destination Options Header. For some it may be a plus - for me this is minus.
>

RFC8200 compliance.

Separating hop-by-hop and destination option processing is good design
because forwarding needs to be as simple and as fast as possible.

Complex packet handling should be left to End-hosts because they're
only performing actions for themselves, so the cost of complex
processing is limited to the end-host that is exclusively benefiting
from it.

Complex packet handing in the network spreads the complexity costs to
all end-hosts attached to the network, even those that don't and may
never benefit from it.

> *E* Unlike say SRH RFC this draft does not even mention once that to impose CRH packets should be encapsulated.
>

While I think it is implicit in RFC8200, it probably should be
explicitly mentioned with a reference to RFC 2473, which shows how to
add new information through EHs to an existing packet via tunnel
encapsulation.

Regards,
Mark.

>> I took a look at these proposals. It's very obvious that the format of CRH is significantly simpler than either of these and is simpler than SRH as well. Complexity in protocol format correlates to how amenable the protocol is to feaible implementation (in HW and SW), how well it can be secured, and how efficient in terms of wire overhead and processing overhead.
>>
>> It is interesting to note that figure Figure 3 in draft-decraene-spring-srv6-vlsid-03 would be identical to Figure 1 in draft-bonica-6man-comp-rtg-hdr-22 if the Last Entry, Flags, Tag, and TLVs fields were removed. Since these fields aren't used in the common case, they are easily compressed by simply removing them. So the material difference between the formats is how the length of SIDs is determined. In CRH this is explicit in the routing type, there is one type for 16-bit SID format and one type for 32-bit format.. AFAICT in vSID the SID length is more like a negotiated parameter that per destination address that uses the same routing type as SRH. While the vSID method might be more flexible and allow arbitrary SID lengths, it leads to more complexity since the routing header can no longer be parsed without external information. For instance, if a management device snoops packets in the path it wouldn't be able to parse the SID list without participating in the protocol that distributes the length information. Similarly, if a legacy SRH receiver receives a vSID header it seems like it would parse it incorrectly.
>>
>> In any case, I don't see why the vSID and CRH proposals couldn't be unified or why SR wouldn't be able to use CRH to convey compressed SIDs.
>>
>> Tom
>>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 May 2020 15:02:19 -0700

> bits could be acceptably accommodated for all cases, so I accept 2
I know from a SW implementation POV it's generally best for fields to
be 2^n bytes in size and have natural alignment to that size (i.e.
offset % 2^n == 0). Fortunately, most IETF L3 and L4 protocols follow
these conventions. For completeness, and because we could encode ILA
or ILNP identifiers, it would be nice to have a 64-bit size also IMO.

> add new information through EHs to an existing packet via tunnel

Note this is implied in the term "source routing". It is only the
source node that can set a routing header. IP-IP encapsulation works
because the encapsulator is the source of the packet as far as the
network is concerned. The CRH protocol format is properly agnostic to
whether the header is being created at the original source or by some
node encapsulating the packet in flight. It might be worth mentioning
since it does seem like a pretty common use case.

Tom

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 May 2020 00:11:25 +0200

Hi Mark,

*Ad *A* & *B* *

No mapping is needed. And I am not talking about variable length IDs in
data plane either. I am talking about exact match locators only without any
mapping. All what is needed is described in our vSID draft. Just borrow
from it :)

Flexible and well thought through choice of encoding does not need to mean
complex data plane .. in fact quite the opposite.

*Ad *C* *

The fact that the problem is not new - does it make it acceptable to
produce more technology with the same problem ? Btw I had a offline chat
with Fred and I think we have an easy fix for it. In fact two cases of it.

*Ad *D* *

Very debatable. Also very much depends if you want segment endpoints to be
able to execute some additional instructions or just blindly forward. That
is one of the fundamental differences here from SRv6.

Not for me to argue either way - just making an observation. Also in all
use cases I see there is no "Complex packet handing" - just basic
forwarding even by encapsulated destination.

*Ad *E* *

Cool.

Rgs,
R.

On Mon, May 18, 2020 at 11:38 PM Mark Smith <[email-masked]> wrote:

> > *A* Requirement for mapping of SIDs to IPv6 addresses - see the header
> may look simple in the draft as the does not talk about mapping. Handwaving
> of config by hand or controller I do not buy.
> >
>
> > *B* Two size will not fit all. Maybe if there is CRH type and we have
> 8,12, 16,24,32 bit SIDs it could be optimal for most deployments
> >
>
> > *D* Separation of destination actions into Destination Options Header.
> For some it may be a plus - for me this is minus.
> >
>
> RFC8200 compliance.
>
> > *E* Unlike say SRH RFC this draft does not even mention once that to
> impose CRH packets should be encapsulated.
> >
>

---

From: Bob Hinden <[email-masked]>
Date: Mon, 18 May 2020 16:08:28 -0700

[Was Adoption call criteria for CRH? [was: Re: CRH and RH0] ]

Hi,

With no hats on:

> On May 18, 2020, at 2:37 PM, Mark Smith <[email-masked]> wrote:

I also prefer a single size (and only one SR header definition).   If it’s 16-bits, that would allow 64K routers in one CRH domain assuming it needs to uniquely identify each router, if there is more than 64K routers, then it only needs to identify the routers that are serving as hops in the source route.

As you note 24 bits is better, but may not align as well.   Or then 32-bits.

Bob

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 19 May 2020 03:53:17 +0000

Bob, I am interested in environments where there are potentially countless billions of
routers. The mobile host is a 20th century archetype; the archetype for the 21st century 
is mobile *routers*. And yes, these can show up as hops in a source route.

Thanks - Fred

> Sent: Monday, May 18, 2020 4:08 PM
> Subject: Size of CR in CRH
> 
> I also prefer a single size (and only one SR header definition).   If it’s 16-bits, that would allow 64K routers in one CRH domain assuming
> it needs to uniquely identify each router, if there is more than 64K routers, then it only needs to identify the routers that are serving
> as hops in the source route.
> 
> >> *C* No mention what happens when node in the SID list is down ... modern networks do not tolerate outages required to signal all
> the way to the ingress to redo computation and start repair from there. This is BAD NETWORK DESIGN.
> >>
> >
> >>> I took a look at these proposals. It's very obvious that the format of CRH is significantly simpler than either of these and is simpler
> than SRH as well. Complexity in protocol format correlates to how amenable the protocol is to feaible implementation (in HW and SW),
> how well it can be secured, and how efficient in terms of wire overhead and processing overhead.
> >>>
> >>> It is interesting to note that figure Figure 3 in draft-decraene-spring-srv6-vlsid-03 would be identical to Figure 1 in draft-bonica-
> 6man-comp-rtg-hdr-22 if the Last Entry, Flags, Tag, and TLVs fields were removed. Since these fields aren't used in the common case,
> they are easily compressed by simply removing them. So the material difference between the formats is how the length of SIDs is
> determined. In CRH this is explicit in the routing type, there is one type for 16-bit SID format and one type for 32-bit format.. AFAICT in
> vSID the SID length is more like a negotiated parameter that per destination address that uses the same routing type as SRH. While
> the vSID method might be more flexible and allow arbitrary SID lengths, it leads to more complexity since the routing header can no
> longer be parsed without external information. For instance, if a management device snoops packets in the path it wouldn't be able to
> parse the SID list without participating in the protocol that distributes the length information. Similarly, if a legacy SRH receiver receives
> a vSID header it seems like it would parse it incorrectly.
> >>>
> >>>>> I’m a little confused about this conversation and I’d like to ask the chairs for clarification. My actual questions are at the end of
> this long(ish) message, and can be summarized as (1) does 6man require consent from SPRING before defining routing headers, and
> (2) what criteria are the chairs using to decide when an adoption call is OK?
> >>>>>
> >>>>> It seems to me there are at least two, only vaguely related, conversations going on. One of them is a debate about the
> assertion that 6man can’t even consider taking up CRH unless SPRING approves it. The other is a more free-wheeling line of
> questioning about “what is CRH for anyway”?
> >>>>>
> >>>>> I have quite a bit of history with how SPRING was chartered; I was one of the original co-chairs and helped write the charter,
> god help me. I can tell you for certain there was no intent that SPRING should have exclusive ownership of source routing in the IETF,
> the name isn’t a power-grab, it’s a clever backronym, as we do in the IETF. If one entity in the IETF were to take charge of all source
> routing, that sounds more like a new area than a WG. But don’t take my word for it, go read the various iterations of the charter. As
> anyone who’s looked at the Segment Routing document set can tell, Segment Routing is one, very specific, way of doing source
> routing. As Ketan and others have pointed out, it’s a pile of architecture plus the bits and pieces to instantiate that architecture. That is
> fine, but the idea that merely because a technology might be used to instantiate part of that architecture, it’s owned by SPRING, is
> overreach. Just because a sandwich is a filling between two pieces of starch, doesn’t mean every filling between two pieces of starch
> is a sandwich. [1]
> >>>>>
> >>>>> But at any rate, the question for the chairs is: do you think 6man needs SPRING’s permission in order to consider adopting
> CRH? Does 6man need permission from SPRING for all routing headers, or just some, and if it’s just some, what characterizes them?
> >>>>>
> >>>>> This seems to me to be exactly the kind of discussion one would normally have in the context of an adoption call. Why is it not
> being had in that context? To rewind back to the interim, if it’s still “too early for adoption call”, what has to happen for it not to be too
> early?
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> —John
> >>>>>
> >>>>> [1] https://cuberule.com

---

From: Bob Hinden <[email-masked]>
Date: Mon, 18 May 2020 22:47:09 -0700

Fred,

> On May 18, 2020, at 8:53 PM, Templin (US), Fred L <[email-masked]> wrote:
> 

I think source routes will be the least of your problem with this.   For example, designing a routing protocol to work at this scale will be a problem.

Bob

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 19 May 2020 14:22:31 +0000

Bob, my estimate of scale may have been a bit overblown; there are only 7 billion
people on the planet so "countless billions" of routers may still be a long way off.
That said, about a routing protocol I believe we can get what we need out of
standard BGP as long as the routers don't move around very much.

Thanks - Fred

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Monday, May 18, 2020 10:47 PM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Bob Hinden <[email-masked]>; Mark Smith <[email-masked]>; 6man <[email-masked]>
> Subject: Re: Size of CR in CRH
> 
> Fred,
> 
> >>>>>> Is it in good interest of anyone deploying segment routing to have to deal with N different non interoperable headers ? Does
> it
> >> make anyone's life easier ?
> >>>>>>
> >>>>>> Kind regards,
> >>>>>> Robert.
> >>>>>>
> >>>>>>> Too bad we have no audio recording, but that’s not too far from my recollection. Anyway, I don’t think I’ve seen this
> answered
> >> on list yet, so I’m asking again.
> >>>>>>>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 19 May 2020 08:09:45 -0700

> standard BGP as long as the routers don't move around very much.
Another possibility is identifier/locator split. For instance, all the
physical devices in many networks are assigned their own /64. In such
cases the routing header can just carry 64 bit locators and no special
mapping or control plane other than standard routing is needed.

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 19 May 2020 18:13:03 +0100

Bob Hinden wrote on 19/05/2020 00:08:
> I also prefer a single size (and only one SR header definition).   If
> it’s 16-bits, that would allow 64K routers in one CRH domain assuming
> it needs to uniquely identify each router, if there is more than 64K
> routers, then it only needs to identify the routers that are serving

Having multiple options for SID size increases complexity at several 
levels: hardware programming, CLI, network compatibility, 
troubleshooting, etc.  What happens if a network wants to change from 
using one type of SID to another because of whatever reason?  Does a 
node need to be configured with multiple IDs?  Can you mix and match? 
These sorts of things matter when you run networks.  You're increasing 
the complexity of some aspects by a factor of two.

Simplicity is a huge gain from an operational point of view.

32 bits has the advantage of being the same size as a node's bgp or ospf 
router-id.  This would be something ranging from helpful to important if 
the device has an option for manual programming.

The EH packet header lookup size of a device obviously impacts this.

Nick

---

From: Ron Bonica <[email-masked]>
Date: Tue, 19 May 2020 18:01:44 +0000

Hi Nick, Bob and Fred

The following factors figured into the decision to specify 2 Routing types, one with a 16-bit identifier and the other with a 32-bit identifier:

	- Today, very few networks contain more than 65,000 routers. So, most networks could obtain best compression with a 16-bit identifier.
	- When 5G is deployed, we may see networks that contain more than 65,000 Cell Site Routers. These networks will need an identifier that is wider than 16 bits.
	- It is unlikely that we will ever see a network that contains more than 4,000,000 routers. So, we will never need an identifier that is wider than 32 bits.

If Routing header types were in short supply, and only one were available to us, we would have to do one of the following:

	- Select a single length (16, 24 or 32 bits)
	- Use the fifth byte of the Routing header to indicate the identifier length.

The first option isn't very appealing. A 16-bit identifier is too short for some networks. A 24-bit identifier may be difficult for some ASICs to process. A 32-bit identifier gives suboptimal compression for all existing networks.

The second option isn't very appealing either. If we use the fifth byte to indicate the identifier length, and we want the first identifier to begin on a 32-bit boundary, the next 24 bits would be wasted.

Fortunately, Routing header types are not in short supply. The Routing Type registry has room for 255 entries. Since it was established 25 years ago, only 6 types have been allocated. Of those, two have been deprecated (RH0 and Nimrod) and two are for special use (Experiment 1 and Experiment 2).

So, allocating two Routing types may be the best solution.

                                                                        Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Nick Hilliard
Sent: Tuesday, May 19, 2020 1:13 PM
To: Bob Hinden <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Size of CR in CRH

Having multiple options for SID size increases complexity at several
levels: hardware programming, CLI, network compatibility, troubleshooting, etc.  What happens if a network wants to change from using one type of SID to another because of whatever reason?  Does a node need to be configured with multiple IDs?  Can you mix and match?
These sorts of things matter when you run networks.  You're increasing the complexity of some aspects by a factor of two.

32 bits has the advantage of being the same size as a node's bgp or ospf router-id.  This would be something ranging from helpful to important if the device has an option for manual programming.

Nick

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 19 May 2020 18:10:59 +0000

Ron, thanks for this explanation and you are certainly welcome to proceed as you are
doing. As you note, there are plenty of Routing header type values available and you
should be able to claim two of them. That will still leave plenty left over for me to claim
one of my own.

Thanks - Fred

> Sent: Tuesday, May 19, 2020 11:02 AM
> To: Nick Hilliard <[email-masked]>; Bob Hinden <[email-masked]>
> Cc: 6man <[email-masked]>
> Subject: RE: Size of CR in CRH
> 
> Hi Nick, Bob and Fred
> 
> The first option isn't very appealing. A 16-bit identifier is too short for some networks. A 24-bit identifier may be difficult for some
> ASICs to process. A 32-bit identifier gives suboptimal compression for all existing networks.
> 
> The second option isn't very appealing either. If we use the fifth byte to indicate the identifier length, and we want the first identifier
> to begin on a 32-bit boundary, the next 24 bits would be wasted.
> 
> Fortunately, Routing header types are not in short supply. The Routing Type registry has room for 255 entries. Since it was established
> 25 years ago, only 6 types have been allocated. Of those, two have been deprecated (RH0 and Nimrod) and two are for special use
> (Experiment 1 and Experiment 2).
> 
> levels: hardware programming, CLI, network compatibility, troubleshooting, etc.  What happens if a network wants to change from
> using one type of SID to another because of whatever reason?  Does a node need to be configured with multiple IDs?  Can you mix
> and match?
> 32 bits has the advantage of being the same size as a node's bgp or ospf router-id.  This would be something ranging from helpful to
> important if the device has an option for manual programming.
> 
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-
> gk!UCWrvkvflbEehBiEIA8M4PHGA_mrvC0MLpZly-euihAg3_3aSjRJLLRAZuRumqRr$

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2020 09:20:07 +1200

> standard BGP as long as the routers don't move around very much.

But when they do move around quite a lot, and frequently go up and down, it seems to me that you are in the area that RPL was designed for, and everything is different from BGP.

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 May 2020 00:35:06 +0100

> So, allocating two Routing types may be the best solution.

yeah, the hardware constraints requirement is troublesome - hey, we're 
all ToR junkies these days - but the more I think about it, the more 
complex this becomes from an operational / implementation point of view, 
for example:

- do you define SID size on a per domain or per node or a per-SID + 
per-node basis?

- if per-domain, how do you implement non-service affecting migration 
from 16-bit to 32-bit?

- without using differentiating CLI syntax, can you manually define a 
mechanism to allow a 16-bit identifier to be configured in a 32-bit SID?

- the distribution protocols needs to become aware of multiple SID sizes

- is (sid16)32768 the same as (sid32)32768. If not, why not? If so, then 
why?  How can this be explained either by or to the TAC agent at 03:00 
over a noisy, laggy phone line in a time-constrained maintenance window 
involving a P1 where neither of you speaks the other's language natively?

- how many segments do you really need to program for actual networks 
(1? 10? 50?), and how deep can you inspect on merchant silicon of today, 
and currently in development? I.e. how badly would your flexibility be 
hobbled if SIDs were one size only?

Nick

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 May 2020 20:49:22 -0400

Ugg.  I had simply assumed that domains would use one or the other size. 
  You are correct Nick, as written so far, a domain could use both 
sizes, as long as any given packet used one or the other.
I would recommend that we write explicitly that a domain SHOULD use only 
one size, and the confusions if one chooses otherwise are on the 
operator who has done that to themselves.

I have been told that there are operators who want 16 bit CRH SIDs and 
operators who want 32 bit CRH SIDs.  That seems to be more significant 
than the minor simplification of defining only one.  I won't cry if the 
working group picks just one.

Yours,
Joel

---

From: Bob Hinden <[email-masked]>
Date: Tue, 19 May 2020 20:05:08 -0700

Ron,

A few comments inline.

> On May 19, 2020, at 11:01 AM, Ron Bonica <[email-masked]> wrote:
> 
> Hi Nick, Bob and Fred
> 

Are there any networks today where 16 bits is too small?

> 	- When 5G is deployed, we may see networks that contain more than 65,000 Cell Site Routers. These networks will need an identifier that is wider than 16 bits.

This seems pretty speculative to me.  Do you have any justification for this?   Is there a 5G document that discusses this?

This is also assuming that each router needs to be identified uniquely and that every router on a path needs to be in the source route.  How long will each path be.   Source routing won’t scale well with large numbers of hops regardless of the size identifier.

> The first option isn't very appealing. A 16-bit identifier is too short for some networks.

s/too short for some networks/too short for some future networks/  ??   Are there any today, even close?

> A 24-bit identifier may be difficult for some ASICs to process. A 32-bit identifier gives suboptimal compression for all existing networks.

So I assume that ASICs can’t process a 32-bit identifier either?

> Fortunately, Routing header types are not in short supply. The Routing Type registry has room for 255 entries. Since it was established 25 years ago, only 6 types have been allocated. Of those, two…

I don’t think the availability of router header types is a good justification for two headers.

Having two headers now adds complexity given what I think I am hearing that there isn’t a need for a bigger identifier for long time in the future.

Bob

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Wed, 20 May 2020 05:09:54 +0000

As srv6 is deployed within a limited domain, however, the ipv6 address of 16 bytes as SRv6 SID has large redundancy information among all SIDs within limited domain deployed by srv6. In fact, 64 bits length is enough for encoding all kind of SIDs in any limited domain for deploying srv6.
 So I think the SID block may use a unified /64 prefix within each srv6 domain, all SIDs for each node regardless of topology SID or service SID within SRv6 domain should be assigned from next 4 bytes from the same /64 srv6 block, next-next 4 byte may be considered as Argument. 
After that, in srv6 domain, the left-most 64 bits of DA field of packet as SID block keep unchanged when packet passing through srv6 domain, only copy right-most 64 bits at SRv6 endpoint from modified-SRH which only include 64 bits for each length-reduced-SID, exclude encoding SID block prefix information in SRH. Of course it still is compatible all existing srv6 control plane extension draft, that is to say complete 128 bits length SID is kept at control plane operation, and no mapping mechanism.  But we can get 50% reduced size in SRH, however, we can still keep the simple forwarding procedure as rfc8754 in forwarding plane. It May be a compromise between SRH size and complex extent of forwarding procedure.

Cheers!

Wang Weibin

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
Sent: 2020年5月19日 23:10
To: Templin (US), Fred L <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Size of CR in CRH

On Tue, May 19, 2020 at 7:23 AM Templin (US), Fred L <[email-masked]> wrote:
>
> Bob, my estimate of scale may have been a bit overblown; there are 
> only 7 billion people on the planet so "countless billions" of routers may still be a long way off.
> That said, about a routing protocol I believe we can get what we need 
> out of standard BGP as long as the routers don't move around very much.
>
Another possibility is identifier/locator split. For instance, all the physical devices in many networks are assigned their own /64. In such cases the routing header can just carry 64 bit locators and no special mapping or control plane other than standard routing is needed.

Tom
> > Cc: Bob Hinden <[email-masked]>; Mark Smith 
> > <[email-masked]>; 6man <[email-masked]>
> > > Bob, I am interested in environments where there are potentially 
> > > countless billions of routers. The mobile host is a 20th century 
> > > archetype; the archetype for the 21st century is mobile *routers*. And yes, these can show up as hops in a source route.
> >
> > >>> I would prefer CR had a singe size of 24 bits, as that would 
> > >>> seem to me to be the Goldilocks size for local network use (16 
> > >>> million values), and per RFC 5505, "Anything that can be 
> > >>> configured can be misconfigured.".
> > >>>
> > >>> However I don't know enough about ASICs to judge whether or not 
> > >>> 24 bits could be acceptably accommodated for all cases, so I 
> > >>> accept 2 sizes, 16 and 32 bits.
> > >>
> > >> it needs to uniquely identify each router, if there is more than 
> > >> 64K routers, then it only needs to identify the routers that are
> > serving
> > >>>> *C* No mention what happens when node in the SID list is down 
> > >>>> ... modern networks do not tolerate outages required to signal
> > all
> > >>> This problem exists with any source routing, and has existed for 
> > >>> many decades in IPv6, IPv4, MPLS and Token Ring source routing. 
> > >>> ICMPv6, routing protocol signalling, BFD, etc. are all existing 
> > >>> solutions to this problem.
> > >>>
> > >>> Separating hop-by-hop and destination option processing is good 
> > >>> design because forwarding needs to be as simple and as fast as possible.
> > >>>
> > >>> Complex packet handling should be left to End-hosts because 
> > >>> they're only performing actions for themselves, so the cost of 
> > >>> complex processing is limited to the end-host that is 
> > >>> exclusively benefiting from it.
> > >>>
> > >>> Complex packet handing in the network spreads the complexity 
> > >>> costs to all end-hosts attached to the network, even those that 
> > >>> don't and may never benefit from it.
> > >>>
> > >>> explicitly mentioned with a reference to RFC 2473, which shows 
> > >>> how to add new information through EHs to an existing packet via 
> > >>> tunnel encapsulation.
> > >>>
> > >>> Regards,
> > >>> Mark.
> > >>>
> > >>>
> > >>>> Thx,
> > >>>> R.
> > >>>>
> > >>>>>> 6man just standardized SRH. Why SRH content can not be filled 
> > >>>>>> by controller and used for the very same purpose as authors
> > >> intend to use CRH for ?
> > >>>>>>
> > >>>>> I took a look at these proposals. It's very obvious that the 
> > >>>>> format of CRH is significantly simpler than either of these 
> > >>>>> and is
> > simpler
> > >> than SRH as well. Complexity in protocol format correlates to how 
> > >> amenable the protocol is to feaible implementation (in HW and
> > SW),
> > >>>>> draft-decraene-spring-srv6-vlsid-03 would be identical to 
> > >>>>> Figure 1 in draft-bonica-
> > >> 6man-comp-rtg-hdr-22 if the Last Entry, Flags, Tag, and TLVs 
> > >> they are easily compressed by simply removing them. So the 
> > >> material difference between the formats is how the length of SIDs is determined. In CRH this is explicit in the routing type, there is one type for 16-bit SID format and one type for 32-bit format..
> > AFAICT in
> > >> vSID the SID length is more like a negotiated parameter that per 
> > >> destination address that uses the same routing type as SRH. While 
> > >> the vSID method might be more flexible and allow arbitrary SID 
> > >> lengths, it leads to more complexity since the routing header can
> > no
> > >> longer be parsed without external information. For instance, if a 
> > >> management device snoops packets in the path it wouldn't be
> > able to
> > >> parse the SID list without participating in the protocol that 
> > >> distributes the length information. Similarly, if a legacy SRH 
> > >> receiver
> > receives
> > >>>>> In any case, I don't see why the vSID and CRH proposals 
> > >>>>> couldn't be unified or why SR wouldn't be able to use CRH to 
> > >>>>> convey
> > >> compressed SIDs.
> > >>>>>
> > >>>>> Tom
> > >>>>>
> > >>>>>> Is it in good interest of anyone deploying segment routing to 
> > >>>>>> have to deal with N different non interoperable headers ? 
> > >>>>>> Does
> > it
> > >>>>>>> I’m a little confused about this conversation and I’d like 
> > >>>>>>> to ask the chairs for clarification. My actual questions are 
> > >>>>>>> at the end
> > of
> > >> this long(ish) message, and can be summarized as (1) does 6man 
> > >> require consent from SPRING before defining routing headers,
> > and
> > >>>>>>> conversations going on. One of them is a debate about the
> > >> assertion that 6man can’t even consider taking up CRH unless 
> > >> SPRING approves it. The other is a more free-wheeling line of questioning about “what is CRH for anyway”?
> > >>>>>>>
> > >>>>>>> Too bad we have no audio recording, but that’s not too far 
> > >>>>>>> from my recollection. Anyway, I don’t think I’ve seen this
> > answered
> > >>>>>>> I have quite a bit of history with how SPRING was chartered; 
> > >>>>>>> I was one of the original co-chairs and helped write the 
> > >>>>>>> charter,
> > >> god help me. I can tell you for certain there was no intent that 
> > >> SPRING should have exclusive ownership of source routing in the
> > IETF,
> > >> the name isn’t a power-grab, it’s a clever backronym, as we do in 
> > >> the IETF. If one entity in the IETF were to take charge of all 
> > >> source routing, that sounds more like a new area than a WG. But 
> > >> don’t take my word for it, go read the various iterations of the charter. As anyone who’s looked at the Segment Routing document set can tell, Segment Routing is one, very specific, way of doing source routing. As Ketan and others have pointed out, it’s a pile of architecture plus the bits and pieces to instantiate that architecture.
> > That is
> > >> fine, but the idea that merely because a technology might be used 
> > >> to instantiate part of that architecture, it’s owned by SPRING, 
> > >> is overreach. Just because a sandwich is a filling between two 
> > >> pieces of starch, doesn’t mean every filling between two pieces 
> > >> of
> > starch
> > >> is a sandwich. [1]
> > >>>>>>>
> > >>>>>>> But at any rate, the question for the chairs is: do you 
> > >>>>>>> think 6man needs SPRING’s permission in order to consider 
> > >>>>>>> adopting
> > >> CRH? Does 6man need permission from SPRING for all routing 
> > >> headers, or just some, and if it’s just some, what characterizes
> > them?
> > >>>>>>>
> > >>>>>>> This seems to me to be exactly the kind of discussion one 
> > >>>>>>> would normally have in the context of an adoption call. Why 
> > >>>>>>> is it
> > not
> > >> being had in that context? To rewind back to the interim, if it’s 
> > >> still “too early for adoption call”, what has to happen for it 
> > >> not to be
> > too
> > >> early?
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>>
> > >>>>>>> —John
> > >>>>>>>
> > >>>>>>> [1] https://cuberule.com
> > >>>>>>> ------------------------------------------------------------
> > >>>>>>> -------- IETF IPv6 working group mailing list [email-masked] 
> > >>>>>>> Administrative Requests: 
> > >>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
> > >>>>>> -------------------------------------------------------------
> > >>>>>> ------- IETF IPv6 working group mailing list [email-masked] 
> > >>>>>> Administrative Requests: 
> > >>>>>> https://www.ietf.org/mailman/listinfo/ipv6
> > >>>> ---------------------------------------------------------------
> > >>>> ----- IETF IPv6 working group mailing list [email-masked] 
> > >>>> Administrative Requests: 
> > >>>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Andrew Alston <[email-masked]>
Date: Wed, 20 May 2020 05:21:41 +0000

Just a few comments on this.

Regarding the SID Size, and basing this on our rather extensive SR-MPLS deployments.  What we have found is that with many many hardware devices limiting the maximum SID size in MPLS to 64k we were running into some operational complexities on our side - nothing that could not be solved. 

It was not the straight up number of devices that was the problem - is was the fact that when running a single consolidated network across multiple countries, what we wanted was to assign a block of SID's to each country out of the same SRGB.  This allows each country operation to know exactly what block they are allocating out of and avoids potential problems of trying to manage all SID allocation from group level.  

This also allowed us to align our SRMS mappings correctly with the address allocations within the specific country.

However, this then creates a situation where you are effectively running into the same problem as address de-aggregation, and because you want those blocks to allow for future expansion etc, you can burn through 64k pretty damn fast when operating across 15 countries.

Now, if I look at CRH - we see a similar thing - where a large network wants to allocate blocks of CRH SID's on a per country basis, yet you are running a single consistent overarching block across the network, the 64k limit is actually a lot smaller than one would imagine.  I would however say that a 16bit CRH SID has a lot of application for smaller networks.

While it is very certainly possible in our scenario to make things work with a 16bit CRH SID, its our view that it would substantially increase complexity from an operational perspective.  Hence, while I certainly support the dual SID sizes, for me, if we had to drop one of them, it would be my preference to stay with the 32bit SID.  As I said though, if the WG does decide either pre or post adoption of the draft to go with one rather than two, I'm not hugely religious about which at t his point, though I see the need for something larger than 16bit becoming very apparent in the future.

Just by way of illustration - if we were to run networks across the entire African continent - which I hope to see us doing one day - as a single network, and we split the 64k block up per country, that only leaves 1213 CRH SID's per country - we use more than that in the SR-MPLS domain in at least 3 countries today.

Andrew

---

From: [email-masked]
Date: Wed, 20 May 2020 11:10:18 +0200

> So, allocating two Routing types may be the best solution.

I don't think we necessarily need to settle this as part of the adoption call.
Although it might influence someone's opionion if this adds 1 (additional) solution to the table or 2.

For clarification:
 - Are these tags meant to be unique within the controlled domain or do they only need to be unique per node?
 - A tag identifies a forwarding method. One node could then use many tags,
   e.g have one tag map to each of it's outgoing interfaces? Or a tag significy a VNI?
 - Method specific parameters. Are they meant to be embedded in the tag or somewhere else, if so where?

Best regards,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Wed, 20 May 2020 16:03:22 +0000

Hi Bob,

AFAICS, a 16-bit identifier is good enough for any network that exists today. And until very recently, I believed that a 16-bit identifier was good enough for any network that might exist for many years to come.

However, 5G may change all of that. The promise of 5G is high data rates from the user-device to the cell tower. In order to achieve these high data rates, the user-device and cell tower communicate with one another over extremely high radio frequencies. These extremely high radio frequencies do not propagate well over long distances. So, there will be *many* cell towers.

The O-RAN Alliance is exploring transport architectures in which each cell tower hosts a Cell Site Router (CSR) and each CSR can be the endpoint of a traffic engineered path. In that architecture, a 32-bit CR may be required, because there may be as many as 1,000,000 CSRs.

Yes, this is a bit speculative. But it may happen.

This is the motivation for having two sizes. We don't want to deprive existing networks of optimal compression because of future speculation. But we don't want to close the door on 5G support, either.

                                                                                                    Ron

P.S. ASICs can generally handle 16, 24 and 32 bit CRs. However, some are more efficient when word-alignment is maintained. This makes 16 and 32 more desirable.

-----Original Message-----
From: Bob Hinden <[email-masked]>
Sent: Tuesday, May 19, 2020 11:05 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Nick Hilliard <[email-masked]>; 6man <[email-masked]>
Subject: Re: Size of CR in CRH

Ron,

A few comments inline.

Bob

> __;!!NEt6yMaO-gk!UCWrvkvflbEehBiEIA8M4PHGA_mrvC0MLpZly-euihAg3_3aSjRJL
> LRAZuRumqRr$

---

From: Bob Hinden <[email-masked]>
Date: Wed, 20 May 2020 09:46:29 -0700

Ron,

Thanks, this is helpful.  Comments inline.

Bob

> On May 20, 2020, at 9:03 AM, Ron Bonica <[email-masked]> wrote:
> 
> Hi Bob,
> 

Good

> However, 5G may change all of that. The promise of 5G is high data rates from the user-device to the cell tower. In order to achieve these high data rates, the user-device and cell tower communicat…

I understand that part of 5G.

> Yes, this is a bit speculative. But it may happen.

CRH could start with a 16-bit identifier.   Once the O-RAN work is further along, a new routing header with 32-bit identifiers could be developed if needed.   As you said, there isn’t a shortage of routing header types and would make the specification and implementations simpler.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 20 May 2020 10:05:33 -0700

Hi Ron,

One quick comment below [Uma]. Apologies, if I interfere between you and
Bob.

--
Uma C.

> AFAICS, a 16-bit identifier is good enough for any network that exists
> today. And until very recently, I believed that a 16-bit identifier was
> good enough for any network that might exist for many years to come.

[Uma]: We all know a typical big SP network (1000 to 2000 nodes) size. If
you take a DC underlay the number is much higher. This is the reason

MSDCs started their journey to BGP only underlay (by giving up fast
convergence and FRR properties). We can all see LSR WG is working  to fix

this to address that space.

So, yes 16 bit identifiers would be  limiting in that case. However in
earlier discussions, some body questioned me what's the use of TE in DC

underalay.  So this leaves us to various access networks and SP networks
(see below on the 5G point).

The other dimension to this is  - number of identifiers in the packet and
that is not proportional to number of nodes in the network, but how many

nodes it ought to traverse to reach the egress node. I guess, this is
simpler to visualize.

>
> However, 5G may change all of that. The promise of 5G is high data rates
> from the user-device to the cell tower. In order to achieve these high data
> rates, the user-device and cell tower communicate with one another over
> extremely high radio frequencies. These extremely high radio frequencies do
> not propagate well over long distances. So, there will be *many* cell
> towers.

> The O-RAN Alliance is exploring transport architectures in which each cell
> tower hosts a Cell Site Router (CSR) and each CSR can be the endpoint of a
> traffic engineered path. In that architecture, a 32-bit CR may be required,
> because there may be as many as 1,000,000 CSRs.

> Yes, this is a bit speculative. But it may happen.

[Uma]: You are correct on NR and small cells. But when 1000000 CSR's where
(which covers a big geographic area of a country like US)? That is

 the missing link above.

a) It is not clear in the industry how NG RAN evolves (off topic) . However
-

b) Looking at where the industry is: your access rings in LTE (biggest
deployments are few 100 nodes).  Even in 5G this will not change

exponentially. But, yes you will more nodes in the ring or you will
sub-tended rings (Olympic rings).

One more thing, you cell site router is extremely cost sensitive. You have
lot more things to worry there even  if the number is even few

thousands in that part (before worrying for exhausting identifier space).

> This is the motivation for having two sizes. We don't want to deprive
> existing networks of optimal compression because of future speculation. But
> we don't want to close the door on 5G support, either.

> P.S. ASICs can generally handle 16, 24 and 32 bit CRs. However, some are
> more efficient when word-alignment is maintained. This makes 16 and 32 more
> desirable.

---

From: Ron Bonica <[email-masked]>
Date: Wed, 20 May 2020 18:40:56 +0000

Bob,

First, let's agree that the problem with having two CRH versions:

- is complexity
- is not code point consumption

Given that agreement, we look for ways to reduce complexity. Options are:

- find ways to reduce complexity while retaining two CRH versions
- drop one CRH version

The following are ways to reduce complexity while retaining two CRH versions:

- Recommend that operators run one CRH version or the other, but not both, except during transition periods
- Facilitate transition by making the 16-bit identifier, with value N, reference the same CRH-FIB entry as the 32-bit identifier that also has value N.

And, of course, we could drop the CRH-32, at least for the time being. But I don't think that this is the right decision because we have heard three arguments for CRH 32, with these being:

- the O-RAN argument (presented by me)
- the Data Center Underlay argument (presented by Uma)
- the sparsely populated identifier argument (presented by Andrew).

While the O-RAN argument may be speculative, the other two are not.

                                                                                                Ron

-----Original Message-----
From: Bob Hinden <[email-masked]>
Sent: Wednesday, May 20, 2020 12:46 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Nick Hilliard <[email-masked]>; 6man <[email-masked]>
Subject: Re: Size of CR in CRH

Ron,

Bob

Good

>>> it’s 16-bits, that would allow 64K routers in one CRH domain 
>>> assuming it needs to uniquely identify each router, if there is more 
>>> than 64K routers, then it only needs to identify the routers that 
>>> are serving as hops in the source route.
>>>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 20 May 2020 12:06:46 -0700

> - is not code point consumption
Ron and Bob,

There's an obvious tradeoff here between flexibility and complexity. I
won't speak for HW implementations, but in a SW datapath
implementations the additional complexity to support different sizes
is relatively slight as long as possible sizes are 2^n, properly
alignment is maintained, there's no additional fields in the header
other than the array, and the values are considered compressed
versions of the largest possible identifier (for example, if 16 bit
SIDs are sent these can be expanded to 32 bits be prepending zeros).
This way, the same code can be used where it's parameterized by
various sizes. From this perspective, I wouldn't mind if there were
three sizes defined: 16, 32, and 64.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Wed, 20 May 2020 19:08:44 +0000

Tom,

I am happy too add a third size if there is WG consensus.

                                        Ron

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Wednesday, May 20, 2020 3:07 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; 6man <[email-masked]>
Subject: Re: Size of CR in CRH

Ron and Bob,

There's an obvious tradeoff here between flexibility and complexity. I won't speak for HW implementations, but in a SW datapath implementations the additional complexity to support different sizes is relatively slight as long as possible sizes are 2^n, properly alignment is maintained, there's no additional fields in the header other than the array, and the values are considered compressed versions of the largest possible identifier (for example, if 16 bit SIDs are sent these can be expanded to 32 bits be prepending zeros).
This way, the same code can be used where it's parameterized by various sizes. From this perspective, I wouldn't mind if there were three sizes defined: 16, 32, and 64.

Tom

> >> Fortunately, Routing header types are not in short supply. The Routing Type registry has room for 255 entries. Since it was established 25 years ago, only 6 types have been allocated. Of those, two have been deprecated (RH0 and Nimrod) and two are for special use (Experiment 1 and Experiment 2)..
> >
> >>> assuming it needs to uniquely identify each router, if there is 
> >>> more than 64K routers, then it only needs to identify the routers 
> >>> that are serving as hops in the source route.
> >>>
> >> -------------------------------------------------------------------
> >> - IETF IPv6 working group mailing list [email-masked] Administrative 
> >> Requests:
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i
> >> pv
> >> 6
> >> __;!!NEt6yMaO-gk!UCWrvkvflbEehBiEIA8M4PHGA_mrvC0MLpZly-euihAg3_3aSj
> >> RJ
> >> L
> >> LRAZuRumqRr$
> __;!!NEt6yMaO-gk!TtOuL3q5ftCTzcAo80NSzIprzqZfGflXimd_USkIaN33XGY6s85mv
> ylu_NBKRGb8$

---

From: Tom Herbert <[email-masked]>
Date: Wed, 20 May 2020 12:13:00 -0700

> I am happy too add a third size if there is WG consensus.
The primary question is probably should there be just one size, or can
there be more than one size (i.e. a choice between 1 an N :-))

Tom

---

From: Ron Bonica <[email-masked]>
Date: Wed, 20 May 2020 19:33:52 +0000

Ole,

Tags have node local scope. And an node may be associated with multiple tags. Assume the following:

- Router R resides in a domain with many other routers
- Router R has 100 neighbors, N1 through N100

So, every router in the network maintains a CRH-FIB entry that contains:

- One of Router R's IP addresses
- A forwarding method indicating that the packet is loosely routed

R's neighbors, N1 through N100, each maintain a second CRH-FIB entry. Each of these contains:

- One of Router R's IP addresses
- A forwarding method indicating that the packet is strictly routed
- An interface identifier

Again, tags have node local scope. However, for the purposes of operational simplicity, an operator might allocate tags that represent loose source routing as if they had domain wide significance. For example, we said that every router in the network maintains a CRH-FIB entry that contains:

- One of Router R's IP addresses
- A forwarding method indicating that the packet is loosely routed

All of these could be identified by the tag R. But this is not strictly required.

                                                                                                                            Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, May 20, 2020 5:10 AM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Size of CR in CRH

For clarification:

Best regards,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 May 2020 23:04:29 +0200

Thanks Ron, that makes sense. 

Cheers,
Ole

> On 20 May 2020, at 21:34, Ron Bonica <[email-masked]> wrote:
> 
> Ole,
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 21 May 2020 07:24:05 +1000

Hi Ron,

> - is not code point consumption

There's an operational issue with having two or more sizes, which is
the risk and possible future consequences of choosing the small size
when you might need the or a larger size in the future.

To change any significant production network from one size to another
is going to involve a lot of planning, may involve disrupting
customers' services, and is likely to involve a lot of out of hours
work. (I like to think of out of hours work as 10 times harder than
in-hours work, so my view is to try to avoid incurring out of hours
work unless there is no other choice.)

In this case of 16 bit verses 32 bits, it sounds like the main cost of
choosing 32 bits will be in ASICs that support them.

So for an operator, it sounds like a choice between writing a bigger
cheque today to buy bigger ASICs, or the possibility of still having
to buy bigger ASICs later (granted, likely cheaper due to natural
scales of economy) and then getting less sleep, disrupting customers
etc. to put the new ASIC equipment in.

I think operators are used to writing pretty big upfront cheques for
equipment, because they're used to buying extra equipment and links
for redundancy, just in case of failures.

Note that I'm not arguing specifically for 32 bits here, just that if
there is a choice between a variety of sizes, the largest choice is
normally the least risky operational choice.

A single single size would be better operationally, as long as that
single size is large enough to cover most use cases. Other special
cases that can't be accommodated sound like they need their own
special and different solution.

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Wed, 20 May 2020 14:32:02 -0700

Speaking strictly for myself...

This is a question:

What is the probability of needing 65536 code points, 131072 code points, etc, etc?

Could the problem of N*0x0ffff code points be addressed by allocating N code points, each of which has 0xFFFF minor code points? Issues include operational overhead and a variety of other things. Note that the usual argument for large prefixes and large numeric groups tend to mention operational overhead.

Discuss...

> On May 20, 2020, at 2:24 PM, Mark Smith <[email-masked]> wrote:
> 
> Hi Ron,
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 20 May 2020 21:54:07 +0000

Fred,

We know that:

- Today, nearly all service provider networks contain fewer than 65K routers. A 16-bit identifier will be good enough for them.
- Today, many Data Centers include more than 65k routers. This number includes software-based routers that reside on servers. They require a 32-bit identifier.
- Today, many service providers have multiple stand-alone operations groups. They may want to allocate a block of identifiers to each group, resulting in sparely populated identifier space. They may require a 32-bit identifier
- In the future, 5G networks may contain as many as 1,000,000 Cell Site Routers. They may require a 32-bit identifier.

                                                                                                                    Ron

-----Original Message-----
From: Fred Baker <[email-masked]>
Sent: Wednesday, May 20, 2020 5:32 PM
To: Mark Smith <[email-masked]>; Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Size of CR in CRH

This is a question:

Discuss...

---

From: Tom Herbert <[email-masked]>
Date: Wed, 20 May 2020 15:15:22 -0700

Mark,

There might be another way to think about this. Suppose CRH is just an
opportunistic compression of some identifier space. For instance,
let's assume that uncompressed SIDs are 128 bits, and the compression
algorithm is not to send leading zeros in a numeric value. Within a 16
bit compressed value we can represent the identifier range 0..2^16-1.
So when a sender is composing a list of identifiers for CRH it can use
the smallest compressed size for which all the values in the list are
within the range for the compressed size.  So, if all the identifiers
are < 2^16 then 16 bits can be used, but if even one value is 2^16
then a larger size is needed (maybe 32 bits if that work). This
compression is lossless and there is only one space, so a compressed
list of identifiers is equivalent to the list of uncompressed
identifiers.

In this way, the network can start out by enumerating the identifiers,
0, 1, 2, 3, ... As long as all the identifiers fit in the smallest
compressed size (say < 2^16) the network can use that in all CRH. But
then at some point, perhaps larger identifiers (>= 2^16) are defined
as the network scales. So now when a node sends a list with one of
those larger identifiers, the sender just uses the next size up
compression (say 32 bits). And the process can repeat itself when
identifiers are greater than 2^32.

So this should eliminate the need for renumbering or reconfiguring
when identifier size increases. The noticeable effect of using larger
identifiers would be reduced compression efficiency-- but there ways
to mitigate that. For instance, make the most commonly used
identifiers low values and the rarely used one the higher values.

Tom

---

From: Bob Hinden <[email-masked]>
Date: Wed, 20 May 2020 16:03:07 -0700

Ron,

> On May 20, 2020, at 2:54 PM, Ron Bonica <[email-masked]> wrote:
> 
> Fred,
> 
> We know that:
> 

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

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

Bob

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 May 2020 01:36:34 +0200

Comment not specific to CRH, but equally meant to apply to 
variable size of an address in other heade parts, eg.
NewIP ? IPv6+, or any of the non-CRH IPv6 steering
headers under consideration:

I think we must stop attempting to recessitate dead memes, or
else we are building crippled zombie technologies: 

In a world where the overwhelming mayority of low-cost
and high speed hardware uses 48 or 20 bit lookups the
power of 2 meme constraint is such a zombie meme.

AFAIK, we only have a subset of actual forwarding ASIC
vendors in this discussion i think, and most of them
have not only technical, but also specific competitive
goals. One of these goals is typically to create as quickly as
possible adoptable standards - with the specific vendors
current HW generation and minimum incremental firmware
development.

This goal bias is a problem for the long-term viability
of the outcome, because the mayority of adoption of
any of this core forwarding technologies will be in
next-generation hardware from a lot more vendors including 
those not present in this discussion and i am very
confident that different sizes will not pose a problem
when they have been an upfront design requirement of a
next-gen chip.

For software equally, i would not bother about those memes
anymore. One counter meme would be to say that 24 bit operations
can be double the speed in SW as ethernet (48) bit operations.
Instruction sets are continuuously enhanced (e.g.: BMI2)
for more flexible memory read/write, and even with older
instruction sets you typically have a lot of instruction
available vs. memory speed. 

I don't think that the WG can do a good job in eliminating
sizes, and i think it should not try to. 
If in doubt whether a stripped down spec will make
all markets happy, i would nowadays always go for more
flexibility. This is different from decades ago, when we
had less ossification and more industry agility. We do
not have that frquent innovation cycles for hardware anymore,
and specs need to support in parallel the possible innovation
cycles across multiple markets.

For example, check out rfc8296. it only mentions 256 as
"default size", but defines 64/128/256/512/1024/2048/4096
And yes, it took a long time (if i remember correctly)
to arrive at this liberal and innovation friendly compromise
or "open ended" spec. Sure, in this case it's all power of
2, but see above, for addresses there are IMHO a lot of
reasons why markets would like a range of addresses
sizes like 16, 20, 24, 32, 48, 64, 96, 128. Just to give
an idea (and this list is definitely not meant for
steering identifier size).

Selecting specific sizes is IMHO an industry decision
and there are a lot of industries now, so no one-size-fits-all.
Heck, there are even a lot of industry bodies
for specific industries that would be happy to define
reqirements profile as a subset of what an IETF spec defined.

Cheers
     Toerless

On Wed, May 20, 2020 at 12:06:46PM -0700, Tom Herbert wrote:
> > CRH could start with a 16-bit identifier.   Once the O-RAN work is further along, a new routing header with 32-bit identifiers could be developed if needed.   As you said, there isn???t a shortage of routing header types and would make the specification and implementations simpler.
> >
> > >
> > > This is also assuming that each router needs to be identified uniquely and that every router on a path needs to be in the source route.  How long will each path be.   Source routing won???t scale well with large numbers of hops regardless of the size identifier.
> > >
> > >
> > > So I assume that ASICs can???t process a 32-bit identifier either?
> > >
> > >>
> > > I don???t think the availability of router header types is a good justification for two headers.
> > >
> > > Having two headers now adds complexity given what I think I am hearing that there isn???t a need for a bigger identifier for long time in the future.
> > >
> > > Bob
> > >
> > >>
> > >>> it???s 16-bits, that would allow 64K routers in one CRH domain

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 May 2020 02:00:10 +0200

Mark:

You are talking about the problem of a design that supports larger sizes
only incrementally over time, but not initially. If the network supports
initially all the future desirable sizes, e.g.: 16 and 32, 64 for example,
you could just start using 16 until you run out. Don't think IP and
v4->v6 renumbering. Think CLNP or E.164 in other countries like the US.
In many european countries, someone who inherited an old phone number
has often up to 4 digits less than poor newcomers ;-)

Cheeers
    Toerless

-- 
---
[email-masked]

---

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

Hi Ron,

Looks like the CRH solution is spread over multiple napkins and you are now taking them out of your pocket one by one 😉

I would wish that everything was documented and put before the WG adoption for a proper evaluation of what it is - i.e. the architecture, applicability, use-cases and requirements.

Thanks,
Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: 21 May 2020 01:04
To: [email-masked]
Cc: 6man <[email-masked]>
Subject: RE: Size of CR in CRH

Ole,

                                                                                                                            Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, May 20, 2020 5:10 AM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Size of CR in CRH

For clarification:

Best regards,
Ole

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 22 May 2020 10:51:21 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: miércoles, 20 de mayo de 2020 18:46
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Size of CR in CRH

<trimmed>

>CRH could start with a 16-bit identifier.   Once the O-RAN work is further along, a new routing header with 32-bit identifiers could be developed if needed.   As you said, there isn't a >shortage of routing header types and would make the specification and implementations simpler.

Bob,

If we consider that CRH-FIB only contains tag entries for each router/prefix in the network, then I agree with you: let's go with 2^16 which is more than enough in a single domain.
However, if we consider the original authors intent of re-spinning SRv6, then you will need Prefix SIDs, Adjacency SIDs, Binding SIDs -and perhaps also BGP EPE SIDs-. In this case the 2^16 number will fall short and likely you need 2^32 tags.

Hence how do we choose in between 16b or 32b? Either we blindly trust the authors, or we need some sort of document understanding what we are trying to solve here as to make the right decision. 

Thanks,
Pablo.