Subject: [Srcomp] 4.1.5. Heterogeneous SID lists

From: Ron Bonica <[email-masked]>
Date: Thu, 29 Oct 2020 16:40:03 +0000

Folks,

I strongly object to the inclusion of "4.1.5. Heterogeneous SID lists" in the document. It is an architectural requirement, which is beyond the scope of this document and out of charter for the design team.

                                                      Ron

Juniper Business Use Only

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 30 Oct 2020 03:29:46 +0000

Team, this is obviously a functional requirement. Without it, operators are entirely unable to build SID lists with compressed and non-compressed SRv6 SIDs.  That may be a tradeoff SPRING is willing to make but we certainly must make this a SHOULD.  Besides the obvious cases we've discussed in our meetings, just this week there is a use case discussed on the 6man alias that requires compressed and non-compressed segments in a single segment list.

I hope other team members can register their analysis on this thread.

Darren
________________________________
From: Srcomp <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Sent: Thursday, October 29, 2020 12:40 PM
To: [email-masked] <[email-masked]>
Subject: [Srcomp] 4.1.5. Heterogeneous SID lists

Folks,

I strongly object to the inclusion of “4.1.5. Heterogeneous SID lists” in the document. It is an architectural requirement, which is beyond the scope of this document and out of charter for the design team.

                                                      Ron

---

From: <[email-masked]>
Date: Fri, 30 Oct 2020 15:53:40 +0800 (CST)

Hi Darren and Ron,

For 4.1.5, I reviewed the previous minutes and the final text that agreed by both of you during DT meeting. 

It is as the following, please see if you can get agreement again for that ?

==============================================================

4.1.5.  Heterogeneous SID lists

Description: The compression solution SHOULD support a combination of  compressed and non-compressed segments in a single path.

Rationale: SRv6 is deployed today, in those networks support of paths with compressed and non-compressed segments improves compression without migrating all SRv6 nodes to the compression solution.  A network deployed with only the compression solution may not realize any advantage from this requirement..

Metric: A compliant compression solution supports both:

   o  classic 128bit SRv6 SIDs in the IPv6 Destination Address field

   o  segment lists (i.e., paths) with both compressed and 128bit SRv6

      SIDs.

==============================================================

Regards,

PSF

原始邮件

发件人：DarrenDukes(ddukes)
收件人：[email-masked];
日 期 ：2020年10月30日 11:31
主 题 ：Re: [Srcomp] 4.1.5. Heterogeneous SID lists

-- 
Srcomp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/srcomp

Team, this is obviously a functional requirement. Without it, operators are entirely unable to build SID lists with compressed and non-compressed SRv6 SIDs.  That may be a tradeoff SPRING is willing to make but we certainly must make this a SHOULD.  Besides
 the obvious cases we've discussed in our meetings, just this week there is a use case discussed on the 6man alias that requires compressed and non-compressed segments in a single segment list.

Darren

--------------------------------------------------------------------------------

Folks,

 

                                                      Ron

---

From: Sander Steffann <[email-masked]>
Date: Fri, 30 Oct 2020 14:11:37 +0100

Hi all,

I realise I am not speaking as a chair anymore, but I just want to 
respond to the following:

> Description: The compression solution SHOULD support a combination of 
>   compressed and non-compressed segments in a single path.
> 
> Rationale: SRv6 is deployed today, in those networks support of paths 
> with compressed and non-compressed segments improves compression without 
> migrating all SRv6 nodes to the compression solution.  A network 
> deployed with only the compression solution may not realize any 
> advantage from this requirement..
> 

We have been here before… Requiring the possibility to put 
non-compressed SIDs in the path is a thinly veiled attempt to require 
the path to be encoded in the "classical" SRH as any other header would 
not be compatible with those non-compressed SIDs.

I am getting really tired of these games, and to be honest the 
continuous effort to sneak requirements in that "SRH" requirement as 
anything stronger as a MAY is one of the reasons I had to resign as a 
chair. I just don't have the energy to play these appalling games.

(1) I just want to state explicitly as an ex-chair that requiring SRH as 
anything more than a MAY (either directly or indirectly) is beyond the 
mandate and charter of this design team.

If the design team decides to violate this mandate after my departure, I 
hereby demand that my name be removed from any resulting documents as I 
do not want to be associated with such behaviour.

Sincerely,
Sander

PS: the paragraph starting with (1) is explicitly written as ex-chair 
and should be read as such. The rest is personal.

PPS: not being a chair anymore does give me more freedom to express my 
personal opinions more bluntly, and I am very disappointed in these 
constant games and the widespread supporting/condoning of that 
behaviour. Shame on you.