Re: [Srcomp] Section 2.3 Paragraph C.1

Weiqiang Cheng <chengweiqiang@chinamobile.com> Sun, 13 June 2021 13:51 UTC

Return-Path: <chengweiqiang@chinamobile.com>
X-Original-To: srcomp@ietfa.amsl.com
Delivered-To: srcomp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4653A1B70 for <srcomp@ietfa.amsl.com>; Sun, 13 Jun 2021 06:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAIZOBl3ZoKA for <srcomp@ietfa.amsl.com>; Sun, 13 Jun 2021 06:51:11 -0700 (PDT)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id CD1553A1B6F for <srcomp@ietf.org>; Sun, 13 Jun 2021 06:51:09 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.11]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee960c60d4246a-5788b; Sun, 13 Jun 2021 21:50:58 +0800 (CST)
X-RM-TRANSID: 2ee960c60d4246a-5788b
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmcc (unknown[10.1.6.6]) by rmsmtp-syy-appsvr06-12006 (RichMail) with SMTP id 2ee660c60d41e86-f479f; Sun, 13 Jun 2021 21:50:58 +0800 (CST)
X-RM-TRANSID: 2ee660c60d41e86-f479f
From: Weiqiang Cheng <chengweiqiang@chinamobile.com>
To: "'Darren Dukes (ddukes)'" <ddukes=40cisco.com@dmarc.ietf.org>, 'Ron Bonica' <rbonica=40juniper.net@dmarc.ietf.org>
Cc: 'Ron Bonica' <rbonica@juniper.net>, srcomp@ietf.org
References: <BL0PR05MB53161A4056DB9AAFCAC9BEC8AE349@BL0PR05MB5316.namprd05.prod.outlook.com> <BN6PR11MB4081E4004DC3C2B037E504A8C8349@BN6PR11MB4081.namprd11.prod.outlook.com>, <BL0PR05MB53167EDA16EA1F5A89AD5943AE349@BL0PR05MB5316.namprd05.prod.outlook.com> <DM6PR11MB4090546C38A27247235DEF07C8349@DM6PR11MB4090.namprd11.prod.outlook.com>, <BL0PR05MB53162DB942B6612FF7121D1FAE339@BL0PR05MB5316.namprd05.prod.outlook.com>, <BN6PR11MB4081D0AE77EDD8B6740346F0C8329@BN6PR11MB4081.namprd11.prod.outlook.com>, <9ABD443C-5E5A-4419-A885-E0DEA5E1E474@juniper.net> <BN6PR11MB4081A3EE26F90709F79C4EF1C8329@BN6PR11MB4081.namprd11.prod.outlook.com>
In-Reply-To: <BN6PR11MB4081A3EE26F90709F79C4EF1C8329@BN6PR11MB4081.namprd11.prod.outlook.com>
Date: Sun, 13 Jun 2021 21:50:57 +0800
Message-ID: <10a601d7605b$236faa10$6a4efe30$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_10A7_01D7609E.3192EA10"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Adde+Afp9RZ3z8O3TDeAx8BwzJmzggACAluJAADCxkAABZ9/uwAIs7DAACzAK8IABOdLcwASIOrNAAMvJIA=
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/srcomp/ry7-DEelVR4TUstvLJzYsylYKkY>
Subject: Re: [Srcomp] Section 2.3 Paragraph C.1
X-BeenThere: srcomp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <srcomp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/srcomp>, <mailto:srcomp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/srcomp/>
List-Post: <mailto:srcomp@ietf.org>
List-Help: <mailto:srcomp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/srcomp>, <mailto:srcomp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Jun 2021 13:51:18 -0000

Hi Darren and Ron,

 

Thanks for working at weekend.

It looks possible to get consensus. 

Is that possible we have a meeting for final text at your Sunday evening and My morning (such as 00:30am,  Monday  UTC time)

 

Monday is the Dragon Boat Festival in China,  which is is best known for its dragon-boat races, especially in the southern provinces where there are many rivers and lakes. 

The festival commemorates the death of Qu Yuan (475-221BC). He was upright, loyal and highly esteemed for his wise counsel that brought peace and prosperity to the people.

 

Hope we can get agreement on the special day J

 

B.R.

Weiqiang Cheng

 

发件人: Srcomp [mailto:srcomp-bounces@ietf.org] 代表 Darren Dukes (ddukes)
发送时间: 2021年6月13日 20:16
收件人: Ron Bonica
抄送: Ron Bonica; srcomp@ietf.org
主题: Re: [Srcomp] Section 2.3 Paragraph C.1

 

Hi Ron. N SR nodes  so still 1000. 

 

With SR nodes As PE nodes, I think N and he result is of the correct order. 

 

The takeaway is forwarding state is on the order of CRH nodes. Additional intermediate nodes are required to mitigate the state. This is inline with moving state from the packet to fib.

 

Darren

 

 

 

 

  _____  

From: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Sent: Saturday, June 12, 2021 11:20 PM
To: Darren Dukes (ddukes)
Cc: Ron Bonica; srcomp@ietf.org
Subject: Re: [Srcomp] Section 2.3 Paragraph C.1 

 

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=40cisco.com@dmarc.ietf.org> 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 <srcomp-bounces@ietf.org> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Sent: Friday, June 11, 2021 11:50 PM
To: Darren Dukes (ddukes); Darren Dukes (ddukes); srcomp@ietf.org
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=40cisco.com@dmarc.ietf.org> 
Sent: Friday, June 11, 2021 7:37 PM
To: Ron Bonica <rbonica@juniper.net>; Darren Dukes (ddukes) <ddukes@cisco.com>; srcomp@ietf.org
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 <srcomp-bounces@ietf.org> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Sent: Friday, June 11, 2021 4:57:57 PM
To: Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org>; srcomp@ietf.org <srcomp@ietf.org>
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=40cisco.com@dmarc.ietf.org> 
Sent: Friday, June 11, 2021 4:33 PM
To: Ron Bonica <rbonica@juniper.net>; srcomp@ietf.org
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" <srcomp-bounces@ietf.org> 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
Srcomp@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/srcomp__;!!NEt6yMaO-gk!WGqwjx_sdlbM15aABFYiJymKl0lGb83YgjsBFlTWM3SPFWOfqMRua1G3VWIz6j0t$