Subject: Re: [Srcomp] 2.3 State Efficiency

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 2 Jun 2021 07:00:35 +0000

Sorry for my late reply.

I agree with the text in this section, at least for C-SID, VSID part. I guess it is ready to be added to the draft.

Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of Darren Dukes (ddukes)
Sent: Tuesday, May 25, 2021 10:26 AM
To: [email-masked]
Subject: [Srcomp] 2.3 State Efficiency

Below is the proposed text for section 2.3 for review.

2.3.  State Efficiency

   The compression proposal SHOULD minimize the amount of additional
   forwarding state stored at a node.

   State efficiency is analyzed at an edge node and in a single sub-
   domain of the SR domain, where three parameters are considered:

   o  N: the number of SRv6 nodes in the sub-domain
   o  I: the number of IGP algorithms [I-D.ietf-lsr-flex-algo]
      configured
   o  A: the number of local adjacency SIDs
   o  D: the number of attached SR sub-domains at a border node
   o  V: the number of VPN services at edge nodes

   For a sub-domain consisting of 1000 SRv6 nodes (N=1000) and some
   number of non-SRv6 nodes, two IGP algorithms (I=2), 100 adjacencies
   per SRv6 node (A=100), up to 10 attached sub-domains per border node
   (D=10), and up to 1000 VPN service segments per edge.

   o  N=1000, I=2, A=100, D=10
   o  V=1000

   UIDSR, CSID and VSID require the following entries:

   o  a FIB entry for the local prefix segment, one per algorithm (I=2).
   o  a FIB entry per local adjacency SID (A=100) **Note1
   o  At border nodes either:

      *  A.1) a FIB entry per domain (D=10) to swap the IPv6 destination
         address prefix.
      *  A.2) a 128-bit SID in the segment list of a packet, requiring
         no additional FIB entries.
   o  At edge nodes, a FIB entry per VPN segment

   CRH requires:

   o  a CFIB entry per CRH node per IGP algorithm for local and remote
      prefix segments (N*I=2000)

      *  One FIB entry per node (N=1000) per IGP algorithm greater than
         1 (per I>1) (N=1000)

         +  IP Flex Algo requires a loopback address per algorithm per
            node

            -  CRH assigns a CFIB entry per loopback
   o  a CFIB entry per local adjacency segment (A=100) **Note1

      *  When non-CRH adjacent nodes are present, additional state is
         required for CRH as per CRH appendix B.

         +  B.1) Up to one CFIB entry per node (N=1000) per local
            adjacency segment (A=100) per algorithm (I=2) to support
            non-CRH adjacent nodes in the sub-domain (N*A*I=200000).
         +  B.2) Up to one CFIB entry per next endpoint if attached to
            non-SR domains and an additional CFIB entry per adjacency to
            support non-CRH adjacent endpoints ((N+A)*I=2200).
   o  At border nodes, assuming two inter-domain links per adjacent
      domain for redundancy, (as per CRH Appendix B) either:

      *  C.1) a CFIB entry per unique endpoint (N*D*I), per inter-domain
         adjacency (2) (N*D*I*2=40000)
      *  C.2) a CFIB entry per unique endpoint (N*D*I), plus inter-
         domain adjacency (2) (N*D*I+2=20002)
  o  At edge nodes, an SRv6 SID FIB entry per VPN segment and a CFIB or
      TPF FIB entry per VPN segment (V*2=2000)

   **Note1: there may be additional adjacency SIDs for protected,
   unprotected, and per algorithm adjacencies, resulting in some
   multiple of A.  This is common for all proposals.

   +----------------------+----------+-----------+----------+----------+
   | 16-bit and 32-bit    | CSID     | CRH       | VSID     | UIDSR    |
   +----------------------+----------+-----------+----------+----------+
   | S(N1000,I2,A100,D10) | *102*    | 2100      | *102*    | *102*    |
   |                      | A.1: 112 |           | A.1: 112 | A.1: 112 |
   |                      | A.2: 102 |           | A.2: 102 | A.2: 102 |
   |                      |          | B.1:      |          |          |
   |                      |          | 202100    |          |          |
   |                      |          | B.2: 4500 |          |          |
   |                      |          | C.1:      |          |          |
   |                      |          | 40000     |          |          |
   |                      |          | C.2:      |          |          |
   |                      |          | 20002     |          |          |
   | S(V1000)             | *1000*   | 2000      | *1000*   | *1000*   |
   +----------------------+----------+-----------+----------+----------+

                         Table 8: Forwarding State

   Conclusion: CSID, VSID and UIDSR minimize forwarding state stored at a node.

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 3 Jun 2021 01:46:28 +0000

I checked again the analysis yesterday, and found out something may be wrong in the text. After discussion with Darren, we confirmed that.

In the table8,  the result of CRH in B.2 case should be (N+A)*I+2100=2200+2100=4300. So the 4500 should be modified to 4300.

Ron, what do you think about this?

Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of Chengli (Cheng Li)
Sent: Wednesday, June 2, 2021 3:01 PM
To: Darren Dukes (ddukes) <ddukes=[email-masked]>; [email-masked]
Subject: Re: [Srcomp] 2.3 State Efficiency

Sorry for my late reply.

Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of Darren Dukes (ddukes)
Sent: Tuesday, May 25, 2021 10:26 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Srcomp] 2.3 State Efficiency

2.3.  State Efficiency

   CRH requires:

---

From: <[email-masked]>
Date: Thu, 3 Jun 2021 20:18:59 +0800 (CST)

Hi Team,

To be honest, for UIDSR a node also needs to maintain the table entries to remote locators, i.e., 1000 entrier in the same domian, maybe 10 aggregation entries for outer domians.

Regards,
PSF

------------------原始邮件------------------
发件人：DarrenDukes(ddukes)
收件人：[email-masked];
日 期 ：2021年05月25日 10:26
主 题 ：[Srcomp] 2.3 State Efficiency
--
Srcomp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/srcomp

---

From: Ron Bonica <[email-masked]>
Date: Wed, 9 Jun 2021 00:17:35 +0000

Cheng,

At tomorrows meeting I will raise objections to B.1, B.2, C.1 and C.2. Each of them assumes that a network architect will choose to increase state as opposed to using two SIDs.

                                                 Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Chengli (Cheng Li)
Sent: Wednesday, June 2, 2021 9:46 PM
To: Chengli (Cheng Li) <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>; [email-masked]
Subject: Re: [Srcomp] 2.3 State Efficiency

[External Email. Be cautious of content]

Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of Chengli (Cheng Li)
Sent: Wednesday, June 2, 2021 3:01 PM
To: Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Srcomp] 2.3 State Efficiency

Sorry for my late reply.

Cheng

2.3.  State Efficiency

   CRH requires:

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 9 Jun 2021 01:38:49 +0000

Ron, it is better to send your idea before the meeting, so that we can save some time on real-time discussion.

Thanks,
Cheng

From: Ron Bonica [mailto:[email-masked]]
Sent: Wednesday, June 9, 2021 8:18 AM
To: Chengli (Cheng Li) <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>; [email-masked]
Subject: RE: 2.3 State Efficiency

Cheng,

                                                 Ron

Juniper Business Use Only
From: Srcomp <[email-masked]<mailto:[email-masked]>> On Behalf Of Chengli (Cheng Li)
Sent: Wednesday, June 2, 2021 9:46 PM
To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Srcomp] 2.3 State Efficiency

Cheng

Sorry for my late reply.

Cheng

2.3.  State Efficiency

   CRH requires:

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 9 Jun 2021 02:58:21 +0000

B.1, B.2, C.1 and C.2 follow the CRH appendix B final paragraph instructions.
This paragraph requires the use of 1 (B.1 and C.1) or 2 (B.2 and C.2) SIDs to represent an adjacency segment.
The operator has the choice to use either B.1 and C.1 or B.2 and C.2 in these cases to support the SRv6 adjacency segment functionality defined in RFC8402.

Darren

On 2021-06-08, 8:18 PM, "Ron Bonica" <rbonica=[email-masked]> wrote:

Cheng,

                                                 Ron

Cheng

Sorry for my late reply.

Cheng

2.3.  State Efficiency

   CRH requires:

---

From: Ron Bonica <[email-masked]>
Date: Wed, 9 Jun 2021 10:44:44 +0000

My idea is to delete them

Sent from my iPhone

On Jun 8, 2021, at 9:39 PM, Chengli (Cheng Li) <[email-masked]> wrote:

Thanks,
Cheng

Cheng,

                                                 Ron

Cheng

Sorry for my late reply.

Cheng

2.3.  State Efficiency

   CRH requires: