RE: RE: some issues in draft-ietf-rtgwg-mrt-frr-algorithm-09
Chris Bowers <cbowers@juniper.net> Thu, 21 April 2016 21:42 UTC
Return-Path: <cbowers@juniper.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D4112E0BB for <rtgwg@ietfa.amsl.com>; Thu, 21 Apr 2016 14:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
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 qdNvH3SyMg7v for <rtgwg@ietfa.amsl.com>; Thu, 21 Apr 2016 14:42:17 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89ADB12E62E for <rtgwg@ietf.org>; Thu, 21 Apr 2016 14:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LcvbG75mjL8dnvvPpUDJ6fnXV2BVB7wwNY8f2MZ0u+o=; b=PdE7/Uhu+ROAg49xBelvF2nV2l9iEGKXXotUUID9icFwXmATa8QYMMjSkPEcGeAHu1SO//Q0hu8D3B6QJrPe/IzgScMckRwAOoEj4VXwjF8BdNkPR8GTA2nLspX7meDz+K0ODiGPlwH1mV5ZO1xW0vnihikad2ahtjjyBuBirXA=
Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB616.namprd05.prod.outlook.com (10.141.218.155) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 21:41:55 +0000
Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 21:41:55 +0000
From: Chris Bowers <cbowers@juniper.net>
To: "peng.shaofu@zte.com.cn" <peng.shaofu@zte.com.cn>
Subject: RE: RE: some issues in draft-ietf-rtgwg-mrt-frr-algorithm-09
Thread-Topic: RE: some issues in draft-ietf-rtgwg-mrt-frr-algorithm-09
Thread-Index: AQHRkHS2eVwbore9XUaAlfRqnD4+75+TYpbwgABzOoCAANZhEA==
Date: Thu, 21 Apr 2016 21:41:55 +0000
Message-ID: <BY2PR05MB61440405E24DABF44264A03A96E0@BY2PR05MB614.namprd05.prod.outlook.com>
References: <OF9599D305.75C430DA-ON48257F8E.000CEF6C-48257F8E.000D3B0B@zte.com.cn> <BY2PR05MB614AF29BBBB0037480F86FEA96D0@BY2PR05MB614.namprd05.prod.outlook.com> <OF972D710F.9AAF5AA6-ON48257F9C.00088EA8-48257F9C.001166AA@zte.com.cn>
In-Reply-To: <OF972D710F.9AAF5AA6-ON48257F9C.00088EA8-48257F9C.001166AA@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: zte.com.cn; dkim=none (message not signed) header.d=none;zte.com.cn; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.239.15]
x-ms-office365-filtering-correlation-id: b14aa7bd-9eed-4cef-2805-08d36a2dc244
x-microsoft-exchange-diagnostics: 1; BY2PR05MB616; 5:LBj1k35r8ORc9nFLrzik3JX/MUzTfSDfQDx9A3B1gQYaW9yV8srttsBYhvYCJe764XbfCnhnuf+RX2AOl4MIeAlIPZ+OH6J1ISZG32N/Imf1Tzxs7pWPD0z/nLy2v/6TX0CrmORQzi6+SvaDiN0GXU5CT13dmCKY9TL6xxr1AUOlh8x+KBPi49EJjcU1dStc; 24:srqDRER/xAt86ji/m3qlO84gdIRO9DxdbQu3miRxF/3lCUnLG4X04pn5e76yJ5mEsY5LuOAIyWAaUBRa6mBRtYsSpl93whWfxiX66lIpGXs=; 7:+p/fIO1u1Lot82ECwuMGgeE1L+9ZXL/W2yUUzvklBWO/1cNGUAgbupFuZNqMt28dZTqmnLQio6Nffx0x4p4vJzixt8h9XONRdNI3E/y1jh5mnxcjMTVDToVRKux7U7T8VlhQdWh0SFdfA70AUvgbs8otMczrtsG9ezij2It1/0+Htvu31LMoVRBdKhqJi+gWPmHk/2XTGegpQDY+7WurGWO8UsdNMxVjq1IhHpu1OPw=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB616;
x-microsoft-antispam-prvs: <BY2PR05MB6162048CCDC237EDC935119A96E0@BY2PR05MB616.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BY2PR05MB616; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB616;
x-forefront-prvs: 091949432C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(377424004)(377454003)(87936001)(5890100001)(5008740100001)(3660700001)(5004730100002)(2501003)(66066001)(3280700002)(77096005)(76576001)(2950100001)(2900100001)(4326007)(10400500002)(92566002)(2351001)(15975445007)(11100500001)(81166005)(76176999)(54356999)(106116001)(230783001)(99286002)(5002640100001)(19300405004)(122556002)(189998001)(586003)(19580405001)(9686002)(110136002)(16236675004)(19625215002)(33656002)(19580395003)(74316001)(1220700001)(19609705001)(790700001)(102836003)(86362001)(5003600100002)(16234385003)(6116002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB616; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR05MB61440405E24DABF44264A03A96E0BY2PR05MB614namprd_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 21:41:55.3597 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB616
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/XXqcHL-2iDIfpbdSXe-V1vV9SrM>
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2016 21:42:23 -0000
Deccan, With respect to the pseudo-code for MRT_Island_Identification(), I understand what you are saying. In fact, the existing Python code has the line intf.remote_intf.IN_MRT_ISLAND = True instead of: intf.remote_node.IN_MRT_ISLAND = True so I will change the pseudocode to match. From what I can tell, the additional if-condition "not intf.IN_MRT_ISLAND" is not absolutely required for correctness, but it is more efficient and clearer, so I will update both the pseudo-code and the Python code. I am still looking into your question about section 5.6 and the topological sort. Thanks for pointing out these issues. Chris From: peng.shaofu@zte.com.cn [mailto:peng.shaofu@zte.com.cn] Sent: Wednesday, April 20, 2016 10:11 PM To: Chris Bowers <cbowers@juniper.net> Cc: rtgwg@ietf.org Subject: 答复: RE: some issues in draft-ietf-rtgwg-mrt-frr-algorithm-09 Hi Chris Thanks for the detailed reply. See inline below with [Deccan] Deccan Chris Bowers <cbowers@juniper.net<mailto:cbowers@juniper.net>> 2016-04-21 05:04 收件人 "peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn>" <peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn>>, 抄送 "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" <rtgwg@ietf.org<mailto:rtgwg@ietf.org>> 主题 RE: some issues in draft-ietf-rtgwg-mrt-frr-algorithm-09 Deccan, Thanks for the feedback. See inline below with [CB]. Chris From: peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn> [mailto:peng.shaofu@zte.com.cn] Sent: Wednesday, April 06, 2016 9:25 PM To: Chris Bowers <cbowers@juniper.net<mailto:cbowers@juniper.net>> Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org> Subject: some issues in draft-ietf-rtgwg-mrt-frr-algorithm-09 Hi Chris There maybe some trivial mistakes in the document, please confirm it. 1) in section "5.2. MRT Island Identification" see pseudo-code in Figure 16, the second if-statement "if (not intf.remote_node.IN_MRT_ISLAND))" will never meet, the BFS will stop abnormally. [CB] I think the issue might be convention we are using in the pseudocode of using the indentation to indicate the scope of if, for, and while statements. We could have chosen to use more explicit scoping like endif, endfor, and endwhile. For this discussion, I rewrote the while loop in figure 16 below using this more explicit scoping. while (explore_list is not empty) next_rtr = remove_head(explore_list) for each intf in next_rtr if (not intf.MRT-ineligible [Deccan] it is necessary to add "not intf.IN_MRT_ISLAND", as the same reason you described. and not intf.remote_intf.MRT-ineligible and not intf.IGP-excluded and (intf in area) and (intf.remote_node supports profile_id) ) intf.IN_MRT_ISLAND = TRUE intf.remote_node.IN_MRT_ISLAND = TRUE [Deccan] so, here the "intf.remote_node" need to be changed to "intf.remote_intf" if (not intf.remote_node.IN_MRT_ISLAND)) intf.remote_node.IN_MRT_ISLAND = TRUE add_to_tail(explore_list, intf.remote_node) endif endif endfor endwhile Written in this form, it is easier to see that we are using the last if-statement to avoid adding to the explore_list any nodes that have already been marked as being in the MRT Island, and are already in the explore_list. If we don’t do this, I think the algorithm will not terminate in some topologies. Did I understand your point correctly? If not, can you clarify more? [Deccan] According to your meaning that if I understand correctly, I put the suggestion directly on the above pseudo-code, please see it. 2) in section "5.7.5. Complete Algorithm to Compute MRT Next-Hops" see pseudo-code in Figure 23, in function "SPF_No_Traverse_Block_Root(spf_root, block_root, direction)", the code "path_metric = min_node.spf_metric + intf.metric" and the following remainder code of this function need to be included in the if-statement "if ( ( ((direction is FORWARD) and intf.OUTGOING) or". [CB] Thanks for catching this error. This is a case where using the indentation to indicate scope made this error less obvious. I will change the indentation of “if ( ( ((direction is FORWARD) and intf.OUTGOING) etc” to correct this. Do the text below now convey the correct meaning? while (spf_heap is not empty) min_node = remove_lowest(spf_heap) Store_Results(min_node, direction) if ((min_node is spf_root) or (min_node is not block_root)) foreach interface intf of min_node if ( ( ((direction is FORWARD) and intf.OUTGOING) or ((direction is REVERSE) and intf.INCOMING) ) and In_Common_Block(spf_root, intf.remote_node) ) path_metric = min_node.spf_metric + intf.metric if path_metric < intf.remote_node.spf_metric intf.remote_node.spf_metric = path_metric if min_node is spf_root intf.remote_node.next_hops = make_list(intf) else intf.remote_node.next_hops = min_node.next_hops insert_or_update(spf_heap, intf.remote_node) else if path_metric == intf.remote_node.spf_metric if min_node is spf_root add_to_list(intf.remote_node.next_hops, intf) else add_list_to_list(intf.remote_node.next_hops, min_node.next_hops) [Deccan] yes. 3) in section "5.9.4. Computing MRT Alternates for Proxy-Nodes" "Similarly, if run Select_Alternates(X, F, primary_intf) and we find that it is safe to USE_BLUE to reach Y" here the first parameter X would be replaced to Y. [CB] Thanks. We will correct this as well. [Deccan] There maybe another issue in section "5.6. Augmenting the GADAG by directing all links". In function "Run_Topological_Sort_GADAG(topo, gadag_root)", because we only first add gadag_root to working_list, but not all other cut-vertexes, it is possible that some blocks have no chance to get Topological_Sort. For example, see Figure 10 (a), the block 3 which contains K, L, M, N, O, P will totally have no chance to get Topological_Sort. To be specific, since the cut-vertex K's all incoming interface have be removed temporarily, note that cut-link H-K is set to bidirectional before Run_Topological_Sort_GADAG, K has no chance to be visited based on the VISIT_ACTION originated from GADAG root. Although in this example all links in block3 have already be directed, we can get another example with a complicated block that will need Topological_Sort to set undirected links. Please see if it is so. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.
- some issues in draft-ietf-rtgwg-mrt-frr-algorithm… peng.shaofu
- RE: some issues in draft-ietf-rtgwg-mrt-frr-algor… Chris Bowers
- 答复: RE: some issues in draft-ietf-rtgwg-mrt-frr-a… peng.shaofu
- RE: RE: some issues in draft-ietf-rtgwg-mrt-frr-a… Chris Bowers
- RE: RE: some issues in draft-ietf-rtgwg-mrt-frr-a… Chris Bowers
- 答复: RE: RE: some issues in draft-ietf-rtgwg-mrt-f… peng.shaofu