Subject: [spring] Thoughts on optimality

From: Tony Li <[email-masked]>
Date: Thu, 16 Sep 2021 15:23:39 -0700

Hi all,

We now seem headed to be adopting both the requirements and analysis drafts and thoughts start to turn towards the debate for selection.

The requirements draft has done a good job documenting our requirements and the analysis draft gives us a perspective on how the various proposals fulfill those requirements, but a deeper nuance is needed to guide us to making an optimal choice.

To that end, it seems to me that three of the requirements are paramount:

- Encapsulation Header Size
- Forwarding Efficiency
- State Efficiency

Of these three, Forwarding Efficiency and State Efficiency seem like they will be overcome by hardware technology.  Continued growth in semiconductors will help us scale here, so the remaing requirement of the Encapsulation Header Size would seem to predominate, and we should therefore optimize for that.

Regards,
Tony

---

From: Bob Hinden <[email-masked]>
Date: Sat, 18 Sep 2021 09:28:38 -0700

Hi,

I think Tony makes an excellent point.   The main purpose of this work is to compress the SRv6 header.  I agree with Tony that the w.g. should focus on the solution that provides the best header compression.

Bob

> On Sep 16, 2021, at 3:23 PM, Tony Li <[email-masked]> wrote:
> 
> 
> Hi all,
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 18 Sep 2021 15:15:16 -0400

+1

Agreed.  As the the goal of the SRv6 compression work is a solution for
encapsulation header size MSD issue for long strict paths, the focus on SRH
header compression of the SRv6 128 bit SID.

>From the analysis draft is stated that each compression solution has
marginal differences and all meet the compression primary objective listed
first in section 6.

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02#section-6

As all the proposals are even as far as encapsulation header size, the
compression analysis  results end up boiling down to other factors shown
below.

6 <https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02#section-6>.
Conclusions

   Encapsulation Header Size

   o  All proposals meet the requirement to reduce the size of the SRv6
      encapsulation header.  Variances between proposals are negligible.

   Forwarding Efficiency

   o  Overall, the CSID parses the fewest headers.  When per packet
      state is processed per segment, CSID, VSID and UIDSR proposals may
      include it in the routing header, CRH may include it in a
      destination option preceding the CRH.

   o  CSID, VSID, and UIDSR require a single lookup to process an
      adjacency or VPN segment.  CRH always requires 2 lookups for VPN
      segments, and 2 and sometimes 3 lookups for adjacency segments.
      All proposals require two lookups to process a prefix segment and
      the next segment.

   State Efficiency

   o  CSID, VSID and UIDSR minimize forwarding state stored at a node.
      CRH moves per segment state from the packet to the FIB.

   SRv6 Based

   o  CSID is SRv6 based, requiring no updates to existing SRv6
      standards, VSID and UIDSR require updates.  CRH is not strictly
      based on SRv6 but is able to provide equivalent functionality.

   SRv6 Functionality

   o  CSID supports SRv6 functionality.  CRH VSID and UID support SRv6
      functionality or equivalent with some new specifications.

   Heterogeneous SID lists

   o  All proposals support heterogeneous SID lists.  CSID and UIDSR
      support heterogeneous SID lists in the SRH, while CRH and VSID
      require installation of binding SIDs at midpoint nodes.

   SID List Length

   o  All proposals support segment lists of at least 16 segments.

   SID Summarization

   o  VSID, CSID and UIDSR support segment summarization, CRH does not.

Thanks

Gyan

On Sat, Sep 18, 2021 at 12:29 PM Bob Hinden <[email-masked]> wrote:

> Hi,
>
> I think Tony makes an excellent point.   The main purpose of this work is
> to compress the SRv6 header.  I agree with Tony that the w.g. should focus
> on the solution that provides the best header compression.
>
> Bob
>
>
> > We now seem headed to be adopting both the requirements and analysis
> drafts and thoughts start to turn towards the debate for selection.
> >
> > The requirements draft has done a good job documenting our requirements
> and the analysis draft gives us a perspective on how the various proposals
> fulfill those requirements, but a deeper nuance is needed to guide us to
> making an optimal choice.
> >
> > Of these three, Forwarding Efficiency and State Efficiency seem like
> they will be overcome by hardware technology.  Continued growth in
> semiconductors will help us scale here, so the remaing requirement of the
> Encapsulation Header Size would seem to predominate, and we should
> therefore optimize for that.
> >
> > Regards,
> > Tony
> >
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Ron Bonica <[email-masked]>
Date: Wed, 29 Sep 2021 21:44:58 +0000

Tony,

Thanks for pointing out that all requirements are not equally important. Some may be extremely important while others are minimally important. Therefore, our analysis should focus on the important requirements.

I agree that Encapsulation Header Size is the most important requirement. I also agree that the Forwarding Efficiency requirement would be important, if it were well-formed. However, I am not sure that it is well-formed.

The Forwarding Efficiency requirement assumes that the only significant factors in forwarding efficiency are:

- Number of lookups
- Number of headers parsed

Are we sure that:

- there isn't a third significant factor that we are leaving out
- the cost of parsing a header may be high on one ASIC and minimal on another

And as you say, next-generation ASICs will be designed to accommodate whatever solution we choose.

                                                                   Ron

Juniper Business Use Only

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Tony Li
Sent: Thursday, September 16, 2021 6:24 PM
To: [email-masked]
Subject: [spring] Thoughts on optimality

[External Email. Be cautious of content]

Hi all,

Regards,
Tony

_______________________________________________
spring mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Te0PqyNCrRUDlLu1jwh3rO2ORVQFKRYu1ylhbeMZRmO1yFomVpfU8XS1Ze-x3fi8$