[Idr] 答复: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Lizhenbin <lizhenbin@huawei.com> Fri, 24 July 2020 09:21 UTC

Return-Path: <lizhenbin@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 D0F983A0CE7 for <idr@ietfa.amsl.com>; Fri, 24 Jul 2020 02:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 jtU0D7gxYJQh for <idr@ietfa.amsl.com>; Fri, 24 Jul 2020 02:21:03 -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 7BC103A0CE6 for <idr@ietf.org>; Fri, 24 Jul 2020 02:21:03 -0700 (PDT)
Received: from lhreml713-chm.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 2627636E32FC7E31F4BE for <idr@ietf.org>; Fri, 24 Jul 2020 10:21:02 +0100 (IST)
Received: from lhreml713-chm.china.huawei.com ( by lhreml713-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 24 Jul 2020 10:21:01 +0100
Received: from DGGEMM404-HUB.china.huawei.com ( by lhreml713-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 24 Jul 2020 10:21:01 +0100
Received: from DGGEMM532-MBX.china.huawei.com ([]) by DGGEMM404-HUB.china.huawei.com ([]) with mapi id 14.03.0487.000; Fri, 24 Jul 2020 17:20:55 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: Robert Raszuk <robert@raszuk.net>, Susan Hares <shares@ndzh.com>
CC: "idr@ietf. org" <idr@ietf.org>
Thread-Topic: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
Thread-Index: AQHWXDt4676AzNM6lUuwhlR/MWgMBakWaoTy
Date: Fri, 24 Jul 2020 09:20:55 +0000
Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D937E6CAE@DGGEMM532-MBX.china.huawei.com>
References: <003701d65aa9$689a64d0$39cf2e70$@ndzh.com>, <CAOj+MMGG6usHpQrn020LwWd7obt8PRPk9oii1drk0UPhyG5_gw@mail.gmail.com>
In-Reply-To: <CAOj+MMGG6usHpQrn020LwWd7obt8PRPk9oii1drk0UPhyG5_gw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D937E6CAEDGGEMM532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fdfI-NePlAFCblATF_WEMonNeEc>
Subject: [Idr] 答复: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
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: Fri, 24 Jul 2020 09:21:06 -0000

Hi Robert,

I think your proposed issue maybe make sense 4/5 years ago. Given the fact that SR policy is widely adopted to

distribute specific SR policy to the specified ingress node through, the dependence of P2MP may be not very useful.

From other perspective, P2P can also be seen as the special case of P2MP. Even in the history of BGP, P2P distribution

can also happen through the control of the local policy. I means there is not absolute boundary.

Best Regards,

Zhenbin (Robin)

发件人: Idr [idr-bounces@ietf.org] 代表 Robert Raszuk [robert@raszuk.net]
发送时间: 2020年7月17日 21:08
收件人: Susan Hares
抄送: idr@ietf. org
主题: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Dear IDR WG,

As discussed previously on the list I strongly object to proceed with this draft any further.

While I am as others quite sceptical about distributing more configuration over BGP this can be said to be debatable especially for p2mp applications.

However including peer's IP address in the NLRI to which given policy applies goes completely AGAINST BGP spray principle of p2mp information distribution. Adding such extension to BGP can only deteriorate the protocol further. It is not a fit in p2mp protocol to by definition use it as p2p transport channel.

The prefix 0 which is in the draft is not the solution to the above problem.

Moreover wide community ATOM also can already contain that peer's address so placing it in the NLRI of MP_REACH is not needed at all.

To the specific questions asked:

Ad 1) No.
Ad 2) No.
Ad 3) No..
Ad 4) No.
Ad 5) Yes.

Kind regards,

On Wed, Jul 15, 2020 at 3:11 PM Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> wrote:
This begins a 2 week WG LC on draft-ietf-idr-rpd
from 7/15 to 7/29/2020.  You can obtain this draft at:

This draft defines a new AFI/SAFI and new atoms
for the Wide Communities.  This WG LC has been delayed
as I waited for a resubmission of the Wide Communities draft.
I had hoped to do these 2 WG LC in parallel.

I’ve not received the Wide Communities draft, but we will
start this WGLC to provide feedback to the authors.
We may have to run a short follow-up to this WG LC
If there are changes to the Wide Communities draft during
Its WG LC.

There is an IPR statement on this draft.

In your responses please answer the following questions:

1) Do you feel this draft has an solution that is acceptable
   With the IPR as a WG RFC?

2) Do you feel this draft is ready to publish?

3) Do you know of implementations of this draft?

4) Do you know of deployments of this draft?
If so, is this feature useful in the deploy ments.

5) Do you feel that Wide Communities is ready for

Cheerily, Susan Hares
Idr mailing list