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

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]

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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

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: 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]
> 
> 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
> 
> [email-masked] <mailto:[email-masked]>
> 
> [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]>
> 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?
>
>
>

---

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.

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

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