iCAN measurement and BFD-//RE: Followup on my comments
"Liubing (Leo)" <leo.liubing@huawei.com> Tue, 30 July 2019 07:51 UTC
Return-Path: <leo.liubing@huawei.com>
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 A18F1120125 for <rtgwg@ietfa.amsl.com>; Tue, 30 Jul 2019 00:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 qMhxo_rm7C7v for <rtgwg@ietfa.amsl.com>; Tue, 30 Jul 2019 00:51:49 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5406120122 for <rtgwg@ietf.org>; Tue, 30 Jul 2019 00:51:48 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 51A0C461DA43AA22A0AB; Tue, 30 Jul 2019 08:51:46 +0100 (IST)
Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 30 Jul 2019 08:51:45 +0100
Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 30 Jul 2019 08:51:45 +0100
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 30 Jul 2019 08:51:45 +0100
Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.174]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0439.000; Tue, 30 Jul 2019 10:03:03 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, RTGWG <rtgwg@ietf.org>
Subject: iCAN measurement and BFD-//RE: Followup on my comments
Thread-Topic: iCAN measurement and BFD-//RE: Followup on my comments
Thread-Index: AdVGeq6KBquThkAzTFKw/WKbVoTggg==
Date: Tue, 30 Jul 2019 02:03:02 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45DA4DF850@dggeml512-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.191.175]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45DA4DF850dggeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/TuuKXS-5oiOwq5UIEZGCKFNMdkg>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 30 Jul 2019 07:51:52 -0000
Dear Greg, (I re-shaped the title for more explicit indication of the topic.) Thanks for your comments, and sorry for my delayed response. Please see my replies inline. From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Monday, July 22, 2019 11:52 PM To: draft-liu-ican@ietf.org; RTGWG <rtgwg@ietf.org> Subject: Followup on my comments Dear Authors, et al., to summarize my comments at the mike: * BFD WG will discuss possible extensions to BFD proposed in draft-mirmin-bfd-extended<https://tools.ietf.org/html/draft-mirmin-bfd-extended-01>. Appreciate your comments to the potential use of the proposed ideas for iCAN. [Bing] Please let me clarify that iCAN was not designed to compete with BFD. They are basically two different things. iCAN is regarding to allowing the routers switch flows between multiple paths autonomously without the involvement of the Controller. In order to do this, the routers also need to do some measurement of the paths. Thus, for the scenarios that already deploy iCAN, we thought it won’t be necessary to enable BFD for the path detection. So, this is a “bonus” for the iCAN scenarios. For general scenarios, especially link failure detection, I believe BFD is still inevitable. * It is my understanding that iCAN enables transient nodes to measure Residence time as defined in Section 2 RFC 8169<https://tools.ietf.org/html/rfc8169#section-2>. Is my understanding of iCAN correct? * in section 4.4 of draft-mirsky-sfc-pmamm<https://tools.ietf.org/html/draft-mirsky-sfc-pmamm-08> we discuss how the Alternate Marking method can be used to measure the Residence Time for an SFF and/or an SF. That can be extended to other overlay and underlay networks. [Bing] iCAN is not aimed for measuring Residence Time; it is about “how congested the path is?”, which is basically a ratio of the Egress-Receiving-Throughput and Ingress-Sending-Throughput on a specific path. In this way, we can get very instant measurement result for very fast flow path adjustment (in our current prototype, it is done every 10ms.). Best regards, Bing Regards, Greg
- iCAN measurement and BFD-//RE: Followup on my com… Liubing (Leo)