IETF Logo Mail Archive

[Dcrouting] A comment on draft-keyupate-idr-bgp-spf

Xuxiaohu <xuxiaohu@huawei.com> Fri, 22 December 2017 08:27 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: dcrouting@ietfa.amsl.com
Delivered-To: dcrouting@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE7D127275 for <dcrouting@ietfa.amsl.com>; Fri, 22 Dec 2017 00:27:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Level:
X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2NX-TbyieOiw for <dcrouting@ietfa.amsl.com>; Fri, 22 Dec 2017 00:27:20 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 849B6126B72 for <dcrouting@ietf.org>; Fri, 22 Dec 2017 00:27:18 -0800 (PST)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D0C6773CFDF0E for <dcrouting@ietf.org>; Fri, 22 Dec 2017 08:27:13 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 22 Dec 2017 08:27:14 +0000
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.57]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Fri, 22 Dec 2017 16:27:07 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "dcrouting@ietf.org" <dcrouting@ietf.org>
Thread-Topic: A comment on draft-keyupate-idr-bgp-spf
Thread-Index: AdN6/qalrWTMjyrZR1yUr/rOo79Zxw==
Date: Fri, 22 Dec 2017 08:27:06 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7141@NKGEML515-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.184.181]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrouting/2FgeNSUej7zgAbHH6JJagY1gR8Y>
Subject: [Dcrouting] A comment on draft-keyupate-idr-bgp-spf
X-BeenThere: dcrouting@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." <dcrouting.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dcrouting>, <mailto:dcrouting-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dcrouting/>
List-Post: <mailto:dcrouting@ietf.org>
List-Help: <mailto:dcrouting-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dcrouting>, <mailto:dcrouting-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Dec 2017 08:27:21 -0000

Hi co-authors of the BGP-SPF draft,

I wonder whether it's worthwhile to consider the coexistence of the traditional BGP-DV protocol and the BGP-SPF protocol on a given node. If so, it seems that we need to maintain separate routing table instances for those two protocols while distinguishing received packets which are corresponding to different routing table instances, e.g., assign a dedicated label for the BGP-SPF routing table instance so as to map received MPLS packets with that label to the corresponding BGP-SPF routing table instance while using policies to map received packets to different routing table instances at the ingress of the BGP-SPF domain), just as what has been done for the performance-based BGP mechanism (https://tools.ietf.org/html/draft-ietf-idr-performance-routing-01).

Best regards,
Xiaohu

v2.23.0 | Report a Bug | By Email