Re: [Srcomp] Section 2.3 Paragraph C.1

[Ron Bonica <[e-mail]>]

Darren,

Much better, but not quite there yet.

If the two (or more) border routers do not support CRH, is N still equal to 1000? Or is it 998?

Are there a good number of CRH capable nodes in the remote domain? If so, we only need routes to the closest. If not, N is smaller than we think.

Ron

Sent from my iPhone

On Jun 12, 2021, at 9:50 PM, Darren Dukes (ddukes) <ddukes=[e-mail]> wrote:



[External Email. Be cautious of content]

Hi Ron, I took the day off from SRComp to enjoy some sunshine, and now I understand your point.

How about we include both scenarios and identify the cases explicitly.  A subdomain without TE, supporting SR only at PE nodes is not uncommon (I fixed a couple math errors in both cases)?

<NEW>
    *  C.1) The remote sub-domain borders support CRH: a CFIB entry
         per CRH node per IGP algorithm for local and remote prefix
         segments (N*I) plus a CFIB entry per local adjacency segment
         (A) plus a CFIB entry per connected remote border router (20)
         (N*I+A+20=2120)
      *  C.2) The remote sub-domain borders do not support CRH: a CFIB
         entry per unique endpoint (N*D*I), plus a CFIB entry per local
         adjacency segment (A), assuming IP flex algo is not implemented
         on non-CRH border domain (I=1), plus inter-domain adjacency
         (20) (N*D*I+2=10120)
</NEW>

PS *Ack ;) we are almost there!*


________________________________
From: Srcomp <[e-mail]> on behalf of Ron Bonica <rbonica=[e-mail]>
Sent: Friday, June 11, 2021 11:50 PM
To: Darren Dukes (ddukes); Darren Dukes (ddukes); [e-mail]
Subject: Re: [Srcomp] Section 2.3 Paragraph C.1

Darren,

Point 1: You are depicting the worst case scenario, where none of the P routers in the metro are CRH aware. If you want to do that, you have to admit that it is the worst case scenario, and one that should be avoided in network designs.

Point 2. If you want to replicate the behavior, map a SID to an anycast address and configure the anycast on D1B1 and D1B2.

P.S. *Do not publish without consensus*

                                                       Ron



Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[e-mail]>
Sent: Friday, June 11, 2021 7:37 PM
To: Ron Bonica <[e-mail]>; Darren Dukes (ddukes) <[e-mail]>; [e-mail]
Subject: Re: Section 2.3 Paragraph C.1

[External Email. Be cautious of content]

Two points.

There is no guarantee of the network between borders. It may be non sr and domains may not directly attached as shown in section 2.

There is a requirement for lossless compression. Srv6 need only use a single sid to reach the endpoint. It would be ecmp load balanced over any available borders. You are suggesting an alternate path for compressed SRv6 with multiple additional sids per border. The calculation, as is, preserves the SRv6 path without loss for compression.


________________________________
From: Srcomp <[e-mail]<mailto:[e-mail]>> on behalf of Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>
Sent: Friday, June 11, 2021 4:57:57 PM
To: Darren Dukes (ddukes) <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Srcomp] Section 2.3 Paragraph C.1


There is a difference between this use case and the one in Appendix B of the CRH draft. In this use case, there are three CRH-capable nodes in the picture. D1B1 only needs to maintain enough state to get the packet to DnB1. DnB1 maintains the state require to get the packet to Dest.



In Appendix B of the CRH draft, there are only two CRH-capable nodes in the picture. So, one has to maintain enough state to get all the way to the other.



                                                                                           Ron







Juniper Business Use Only

From: Darren Dukes (ddukes) <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>
Sent: Friday, June 11, 2021 4:33 PM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: Section 2.3 Paragraph C.1



[External Email. Be cautious of content]



This is not what Appendix B of CRH draft says.  It says to instantiate state for every endpoint D1-DN at P.  Recall the destination is not a remote border node but a remote PE or segment in a remote SR sub-domain.





On 2021-06-11, 4:11 PM, "Srcomp" <[e-mail]<mailto:[e-mail]>> wrote:



Darren,



I think that Section 2.3 Paragraph C1 has a bug in it.



Assume that we have 11 domains, D1 through D11. Each domain has two border routers, B1 and B2. The B1 router in Domain D1 is connected to the B1 router in all of the other domains (10 connections). Likewise, the B2 router in Domain D1 is connected to all of the B2 routers in the other domains (another 10 connections).



The border routers in Domain D1 maintains state for:



-          All of the routers in D1 (N = 1000)

-          All of the border routers in Domains D2 through D11 (N = 20)



With only that amount of state, any node in Domain D1 can reach any destination in Dn using either of the following paths:



-          D1B1, DnB1, Dest

-          D1B2, DnB2, Dest



D1B1 doesn’t need to maintains state for dest, because DnB1 does.



So, C1 should read:



OLD>

a CFIB entry per unique endpoint (N*D*I), assuming IP flex  algo is not implemented on non-CRH domain (I=1), plus inter- domain adjacency (2) (N*D*I+2=10002) *RON-REVIEW*

<OLD

NEW>

a CFIB entry per CRH node per IGP algorithm for local and remote  prefix segments (N*I=2000) plus a CFIB entry per local adjacency segment (A=100) plus a CFIB entry per connected remote border router (20)

<NEW



So, the value of C.1 should 2102, not 10002.



                                                                                                    Ron









Juniper Business Use Only

--
Srcomp mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/srcomp__;!!NEt6yMaO-gk!WGqwjx_sdlbM15aABFYiJymKl0lGb83YgjsBFlTWM3SPFWOfqMRua1G3VWIz6j0t$