Re: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

["Chengli (Cheng Li)" <[e-mail]>]

Hi Ron,

We may try to provide some text of rationale before dropping it?

I think the state efficiency is important for a solution. But some optimizations can reduce the state of a solution for sure.

How about let's try to provide a better rationale and metric. When we are analyzing solutions, some conditions can be provided to adjust the results?


I try to add some text of the rationale.

   o  Rationale: Additional state will increase the complexity of control plane and data plane at a node. Also, removing per-flow state at middle nodes is the key advantage of SR architecture, which can simplify the network. The compression solution SHOULD NOT introduce extra state.

Regarding the Metric, does the state equal to the number of FIB entries? I doubt that.

   o  Metric:The state efficiency metric (S) records the number of
      additional FIB entries (states) required by the proposed solution.

      *  S(node parameters): the number of additional FIB entries for a
         node, given a set of node parameters consisting of number of
         nodes in the network, number of local interface, number of
         adjacencies.


Respect,
Cheng





From: Srcomp [mailto:[e-mail]] On Behalf Of Ron Bonica
Sent: Thursday, September 24, 2020 3:27 AM
To: srcomp <[e-mail]>
Subject: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

Folks,

The description and the rationale are identical. Lacking rationale to justify this requirement, we should drop it.

The metric regarding  REQ-8-17-STATE-EFFICIENCY assumes that one can infer how many FIB entries a particular compression mechanism requires. It ignores the fact that a FIB can be organized in many ways. Some organizations will have more FIB entries than others.

Unless we can develop a better metric, this requirement should be dropped.


                                             Ron



Juniper Business Use Only