Re: [Srcomp] 2.3 State Efficiency

[Ron Bonica <[e-mail]>]

My idea is to delete them

Sent from my iPhone

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



[External Email. Be cautious of content]

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:[e-mail]]
Sent: Wednesday, June 9, 2021 8:18 AM
To: Chengli (Cheng Li) <[e-mail]>; Darren Dukes (ddukes) <ddukes=[e-mail]>; [e-mail]
Subject: RE: 2.3 State Efficiency

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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Chengli (Cheng Li)
Sent: Wednesday, June 2, 2021 9:46 PM
To: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>; Darren Dukes (ddukes) <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Srcomp] 2.3 State Efficiency

[External Email. Be cautious of content]

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:[e-mail]] On Behalf Of Chengli (Cheng Li)
Sent: Wednesday, June 2, 2021 3:01 PM
To: Darren Dukes (ddukes) <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Srcomp] 2.3 State Efficiency

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:[e-mail]] On Behalf Of Darren Dukes (ddukes)
Sent: Tuesday, May 25, 2021 10:26 AM
To: [e-mail]<mailto:[e-mail]>
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.