Subject: [Srcomp] Section 4.1.1.1

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Nov 2020 02:14:59 +0000

Folks,

The following is proposed text for Section 4.1.1. Please review and comment.

                                             Ron

Description
=========

The compression mechanism SHOULD comply with RFC 8402. However, it MAY extend RFC 8402.

The compression mechanism MAY, but is not required to, reuse existing protocol machinery. To the degree that the compression mechanism reuses SRv6 protocol machinery, it SHOULD comply with:

         +  [RFC8754].

         +  [I-D.ietf-spring-srv6-network-programming].

         +  [I-D.ietf-spring-segment-routing-policy].

      *  Along with the other working group control plane and OAM
         specifications

         +  [I-D.ietf-lsr-isis-srv6-extensions].

         +  [I-D.ietf-bess-srv6-services].

         +  [I-D.ietf-idr-bgpls-srv6-ext].

         +  [I-D.ietf-spring-sr-service-programming].

         +  [I-D.ietf-6man-spring-srv6-oam].

However, the compression mechanism MAY extend the above-mentioned specifications.

To the degree that the compression mechanism does not reused SRv6 protocol machinery, it MUST provide equivalent functionality using other mechanisms.

Juniper Business Use Only

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 9 Nov 2020 11:50:15 +0000

Hi team, this proposed text does not provide a requirement. It says any proposed solution, using any data plane or control plane, is equivalent to a solution using the existing SRv6 data plane and control plane.  This is of course not true. SRv6 is standardized with many deployments and many more by the time a compression solution is standardized.  A performant solution based on existing standards is preferred vs a new control plane and data plane.  This is not valid candidate text for section 4.1.1.

- “MAY” is NOT a requirement
- Functional equivalence is assessed in 4.1.2.
- RFC1958 -> Re-use of existing solution (with equivalent functionality) is an architectural principle of the Internet
- Operators with existing SRv6 deployments (likely hundreds by the time any compression solution is standardized) would prefer a solution that
  - Is mature
  - They are familiar with
  - Can be deployed incrementally
  - Can be seamlessly integrated with other SRv6 functionalities that do not require compressed SIDs (mobility, SFC, host networking, VPN)

________________________________
From: Srcomp <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Sent: Sunday, November 8, 2020 9:14 PM
To: srcomp <[email-masked]>
Subject: [Srcomp] Section 4.1.1.1

Folks,

                                             Ron

Description

=========

         +  [RFC8754].

         specifications