[Idr] Augmenting the ietf-routing in two separate drafts

Qin Wu <bill.wu@huawei.com> Thu, 23 May 2019 06:35 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D385612012A for <idr@ietfa.amsl.com>; Wed, 22 May 2019 23:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Y6_8nUDrTJAI for <idr@ietfa.amsl.com>; Wed, 22 May 2019 23:35:34 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 EF3001200D6 for <idr@ietf.org>; Wed, 22 May 2019 23:35:33 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 8B4059E4EA3D9DAEE4D0 for <idr@ietf.org>; Thu, 23 May 2019 07:35:31 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com ( by lhreml702-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 23 May 2019 07:35:31 +0100
Received: from NKGEML513-MBX.china.huawei.com ([]) by nkgeml412-hub.china.huawei.com ([]) with mapi id 14.03.0415.000; Thu, 23 May 2019 14:35:27 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Augmenting the ietf-routing in two separate drafts
Thread-Index: AdURMasPr5sr3922T1G2paG7SAZm3Q==
Date: Thu, 23 May 2019 06:35:26 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA4948C9D@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA4948C9Dnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/wFO5tzFA2HYfcOO99N-yLPpggME>
Subject: [Idr] Augmenting the ietf-routing in two separate drafts
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2019 06:35:36 -0000

Hi, authors and all:
It is not clear to me why we define augmentation of the ietf-routing in two different draft, one is in the draft-ietf-rtgwg-yang-rib-extend-01 which augment common rib building block in ietf-routing with multiple next-hop support,
The other is in the BGP YANG model (https://tools.ietf.org/html/draft-ietf-idr-bgp-model-05#section-2.3) which augment ietf-routing with BGP RIB specific parameters.
I would suggest to factor out BGP RIB into a separate draft or draft-ietf-rtgwg-yang-rib-extend-01 and define lightweight BGP model and move forward.
Let me know if you have disagreement on this.