Subject: Re: [Srcomp] REQ-7-27-ARCH-01

From: Sander Steffann <[email-masked]>
Date: Tue, 28 Jul 2020 21:27:08 +0200

Hi Darren,

> On 28-07-2020 05:37, Darren Dukes (ddukes) wrote:
> ARCH, Architecture Compliance
> 
> Description:
> A solution to compress SR for the IPv6 dataplane MUST be compatible with
> the specifications describing the instantiation of SR for the IPv6
> dataplane including:
> - RFC8402
> - RFC8754
> - draft-ietf-spring-srv6-network-programming
> - draft-ietf-spring-segment-routing-policy
> 
> Along with the other working group control plane and OAM specifications
> draft-ietf-lsr-isis-srv6-extensions
> draft-ietf-bess-srv6-services
> draft-ietf-idr-bgpls-srv6-ext
> draft-ietf-spring-sr-service-programming
> draft-ietf-6man-spring-srv6-oam

I'm sorry Darren, you seem to have misunderstood the purpose of this
design team. Taking SRv6 for granted is NOT part of the mandate…

Cheers,
Sander

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 29 Jul 2020 01:26:17 +0000

Hello Sander

Perhaps you would like to state your technical objection with this proposed requirement.
Do you believe it is NOT desirable for SPRING to reuse the SRv6 specifications it standardized for the compressed SRv6 solution?

I've re-added the rationale and metric to the thread to maintain context.

Thanks
  Darren

________________________________
From: Srcomp <[email-masked]> on behalf of Sander Steffann <[email-masked]>
Sent: Tuesday, July 28, 2020 3:27 PM
To: [email-masked] <[email-masked]>
Subject: Re: [Srcomp] REQ-7-27-ARCH-01

Hi Darren,

Rationale:
Building upon multiple years of work by SPRING to define SRv6 (the instantiation of SR on the IPv6 data plane) builds on the collaboration, review, implementations, and deployments associated with this work.
It is desirable for SPRING to reuse the SRv6 specifications for any compressed SRv6 solution.

Metric:
 The compliance metric (C) records how aligned a proposal is with the
   SRv6 solution.

   o  C.RFC8402: compliance with [RFC8402]
   o  C.SRH: compliance with [RFC8754]
   o  C.PGM: compliance with [I-D.ietf-spring-srv6-network-programming]
   o  C.IGP: compliance with [I-D.ietf-lsr-isis-srv6-extensions]
   o  C.BGP: compliance with [I-D.ietf-bess-srv6-services]
   o  C.POL: compliance with [I-D.ietf-spring-segment-routing-policy]
   o  C.BLS: compliance with [I-D.ietf-idr-bgpls-srv6-ext]
   o  C.SVC: compliance with [I-D.ietf-spring-sr-service-programming]
   o  C.OAM: compliance with [I-D.ietf-6man-spring-srv6-oam]

   Each of the above metrics are assigned a compliance value:
   o  10: complies with the specification
   o  5: extends the specification
   o  0: redefines the specification

   C.TOT is the sum of all C.* metrics listed above.  It provides an
   overall assessment of the proposal's alignment with the SRv6 RFCs and
   working group drafts.

Cheers,
Sander

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

---

From: Sander Steffann <[email-masked]>
Date: Wed, 29 Jul 2020 06:07:04 +0200

Hi Darren,

> Perhaps you would like to state your technical objection with this proposed requirement.

This is not a technical objection, but a point of order.

One of the reasons this team exists is to determine whether there is a need for alternatives.

I'm fine with looking at compatibility with SRv6/SRH in the analysis, but not as a metric. That would cause a bias against alternatives being proposed, which goes against the goal of this design team.

Cheers,
Sander

---

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

Hi Sander. This team exists to produce requirements and analyze proposals against the requirements.

we are specifically directed to not make determinations nor decisions, just provide the data for spring to do it’s work.

To that end I believe it is crucial that we tell spring the degree to which proposals build on the work spring has done.

This is not bias, just good thorough analysis.

Darren

________________________________
From: Sander Steffann <[email-masked]>
Sent: Wednesday, July 29, 2020 12:07 AM
To: Darren Dukes (ddukes)
Cc: [email-masked]
Subject: Re: [Srcomp] REQ-7-27-ARCH-01

Hi Darren,

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Thu, 30 Jul 2020 00:08:47 +0200

Hi Darren,

> To that end I believe it is crucial that we tell spring the degree to which proposals build on the work spring has done.

As I said: I'm fine with looking at compatibility with SRv6/SRH in the analysis. But this design team needs to look forward to what requirements the wider operator community has, not at the sunk cost of the work in spring.

I agree that we should analyse that, but not as a requirement.

Cheers,
Sander