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$
- [Srcomp] Section 2.3 Paragraph C.1 Ron Bonica
- Re: [Srcomp] Section 2.3 Paragraph C.1 Darren Dukes (ddukes)
- Re: [Srcomp] Section 2.3 Paragraph C.1 Ron Bonica
- Re: [Srcomp] Section 2.3 Paragraph C.1 Darren Dukes (ddukes)
- Re: [Srcomp] Section 2.3 Paragraph C.1 Ron Bonica
- Re: [Srcomp] Section 2.3 Paragraph C.1 Darren Dukes (ddukes)
- Re: [Srcomp] Section 2.3 Paragraph C.1 Ron Bonica
- Re: [Srcomp] Section 2.3 Paragraph C.1 Ron Bonica
- Re: [Srcomp] Section 2.3 Paragraph C.1 Darren Dukes (ddukes)
- Re: [Srcomp] Section 2.3 Paragraph C.1 Weiqiang Cheng
- Re: [Srcomp] Section 2.3 Paragraph C.1 Ron Bonica
- Re: [Srcomp] Section 2.3 Paragraph C.1 Ron Bonica
- Re: [Srcomp] Section 2.3 Paragraph C.1 Darren Dukes (ddukes)