[Idr] 答复: WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.

Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 11 June 2020 07:57 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
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 19D863A175F for <idr@ietfa.amsl.com>; Thu, 11 Jun 2020 00:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id we7-WRZ5YHa2 for <idr@ietfa.amsl.com>; Thu, 11 Jun 2020 00:57:37 -0700 (PDT)
Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FE53A175E for <idr@ietf.org>; Thu, 11 Jun 2020 00:57:36 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown []) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 82BB148F3D; Thu, 11 Jun 2020 15:56:29 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'Susan Hares'" <shares@ndzh.com>, "'idr@ietf. org'" <idr@ietf.org>
References: <005901d63ab5$d6003e00$8200ba00$@ndzh.com>
In-Reply-To: <005901d63ab5$d6003e00$8200ba00$@ndzh.com>
Date: Thu, 11 Jun 2020 15:56:28 +0800
Message-ID: <007801d63fc5$d02e49d0$708add70$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0079_01D64008.DE549710"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJt5doQ6e6HVnKlM9657bF+XPJm0aejvVdQ
Content-Language: zh-cn
X-HM-Tid: 0a72a2615e2a9865kuuu82bb148f3d
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/DZlF6-8dU96vPbdIYFx3cIgdwJo>
Subject: [Idr] =?gb2312?b?tPC4tDogIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1i?= =?gb2312?b?Z3Atb3Blbi1wb2xpY3ktMTAudHh0ICg2LzQgdG8gNi8xOCkoLg==?=
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, 11 Jun 2020 07:57:40 -0000

Can the authors give more explanation on the following description in


There are peering relationships that are 'complex', i.e., both

   parties are intentionally sending prefixes received from each other

   to their non-transit peers and/or transit providers.  If multiple BGP

   peerings can segregate the 'complex' parts of the relationship, the

   complex peering roles can be segregated into different normal BGP

   sessions, and BGP Roles MUST be used on each of the resulting normal

   (non-complex) BGP sessions.


Some figures or more detailed explanations will be helpful to get the
description of “complex”.  Is there any situation that the multiple BGP
peering can’t be segregated?



Best Regards


Aijun Wang

China Telecom


发件人: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] 代表 Susan Hares
发送时间: 2020年6月5日 5:20
收件人: 'idr@ietf. org' <idr@ietf.org>
主题: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.


This begins a 2 week WG LC for draft-ietf-idr-bgp-open-policy-10.txt

>From 6/4 to 6/18/2020.  


There are 3 implementations:   BIRD (1.76, 2.05) , FRR, and Mikrotik. 

The BIRD and FRR implementations interoperate. 

I do not have details on Mikrotik.  


Details on the  interoperability are on the following IDR wiki page: 



Only one  error handling issues exists on the ability of BIRD 

to send Role Mismatch (Open Error (2), subcode 8).  

Another protocol was assigned to subcode 8.  


Please comment on the following questions: 

1) Is this specification ready for publication? 

2) Are there deployments where this BGP protocol extension is valuable? 

3) Do you believe the error code handling is ready for publication? 


The shepherd for this draft is Susan Hares.  

During the WG LC, the shepherd’s report will be sent.