Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3 State Efficiency

[Ron Bonica <[e-mail]>]

Cheng,

I think that we reached the same conclusion. Your comment will be perfectly appropriate on the 6man mailing list when the CRH discussion reopens. I look forward to continuing this discussion at that time.

                                                                                                                         Ron




Juniper Business Use Only
From: Chengli (Cheng Li) <[e-mail]>
Sent: Monday, June 7, 2021 8:34 AM
To: Ron Bonica <[e-mail]>
Cc: [e-mail]; Darren Dukes (ddukes) <[e-mail]>
Subject: RE: [Srcomp] Questions of CRH Appendix B. RE: 2.3 State Efficiency

[External Email. Be cautious of content]

Well, State performance. But this part is written in your CRH draft, so it may be fine, I can comment it in another thread.

This thread is for State efficiency, and I think the data in this section is correct☺, so maybe nothing else.

Respect,
Cheng




From: Srcomp [mailto:[e-mail]] On Behalf Of Ron Bonica
Sent: Monday, June 7, 2021 8:09 PM
To: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Darren Dukes (ddukes) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3 State Efficiency

Ching Li,

Which requirement are we discussing?

Ron
Sent from my iPhone

On Jun 7, 2021, at 3:27 AM, Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>> wrote:

[External Email. Be cautious of content]

Hi Ron,

I guess it is clear that we need P to maintain END SID for each Dn,
or maybe we should add text to describe that it is a common case that a node will maintain the received SID for SPF.

The Adj SIDs are allocated by the node P triggered by received prefix SIDs of Dn, so the Prefix SIDs MUST be counted.

Thanks,
Cheng




From: Ron Bonica [mailto:[e-mail]]
Sent: Saturday, June 5, 2021 2:50 AM
To: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>; Darren Dukes (ddukes) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Questions of CRH Appendix B. RE: 2.3 State Efficiency

Hi Cheng,

OK. Now I can find the text to which you refer 😉

It is not clear that P maintains an END SID for each Dn. If it already has 2 END.X SIDs for each Dn, the path computation element (whether it is a controller or the SR ingress node) can load balance between those.

                                                                                                           Ron




Juniper Business Use Only
From: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, June 2, 2021 11:35 PM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>; Darren Dukes (ddukes) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Questions of CRH Appendix B. RE: 2.3 State Efficiency

[External Email. Be cautious of content]

Hi Ron,

I am not really sure about that. I mean the Appendix B in your draft[1].

I reread CRH draft yesterday and learned a lot, appreciated!

Thanks,
Cheng


[1].https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr-26#appendix-B




From: Srcomp [mailto:[e-mail]] On Behalf Of Ron Bonica
Sent: Thursday, June 3, 2021 11:30 AM
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] Questions of CRH Appendix B. RE: 2.3 State Efficiency

Chengli,

I don’t see Appendix B in version 01-6 or 01-7. Didn’t we agree to drop it from the document?

                                                                          Ron



Juniper Business Use Only
From: Srcomp <[e-mail]<mailto:[e-mail]>> On Behalf Of Chengli (Cheng Li)
Sent: Wednesday, June 2, 2021 10:02 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: [Srcomp] Questions of CRH Appendix B. RE: 2.3 State Efficiency

[External Email. Be cautious of content]

Hi Ron,

I get confused of the analysis in CRH appendix B[1], hope to discuss with you.


   CRH compressed SRv6 can encode this SR Path in two or three segments.
   When it encodes the path in two segments, one segment instantiated on
   P and the other on the destination.  [It seems like something wrong here?]To support this strategy, P
   instantiates 2*N SIDs (one per network per destination).

First of all, the node P maintains a N FIB for Dn for SPF forwarding, correct?
For forwarding the packet to a specific interface, 2N FIB entries are maintained?
Furthermore, 1 prefix CRH SID for node P is maintained as well?

So the sum should be N+2N+1 =3N+1?


   When CRH
   compressed SRv6 encodes the path in three segments, two segments are
   instantiated on P and the other on the destination.  The first
   segment on P updates the IPv6 Destination address without forwarding
   the packet, while the other segment on P forwards the packet without
   updating the IPv6 destination address.  To support this strategy, P
   instantiates 2+N SIDs (one per network and one per destination).

For this, it should be 1 Prefix + 2 adj + N =3+N？

Thanks,
Cheng

[1].https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr-26#appendix-B





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.
--
Srcomp mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/srcomp__;!!NEt6yMaO-gk!WbqYjbh_CvrBXjxxlG0ViQmY7JXzHw6k_PUp7d_BuZuiyCRV-XAupHD5LE_zC8Ip$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/srcomp__;!!NEt6yMaO-gk!WbqYjbh_CvrBXjxxlG0ViQmY7JXzHw6k_PUp7d_BuZuiyCRV-XAupHD5LE_zC8Ip$>