Re: [Idr] [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt

Mach Chen <mach.chen@huawei.com> Fri, 11 June 2021 09:16 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2913A3054; Fri, 11 Jun 2021 02:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 1BjAnmk_98B3; Fri, 11 Jun 2021 02:15:55 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE313A3034; Fri, 11 Jun 2021 02:15:55 -0700 (PDT)
Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G1Zhg4XQTz6L78L; Fri, 11 Jun 2021 17:06:27 +0800 (CST)
Received: from dggpemm100004.china.huawei.com (7.185.36.189) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 11 Jun 2021 11:15:52 +0200
Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm100004.china.huawei.com (7.185.36.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 11 Jun 2021 17:15:50 +0800
Received: from dggpemm500002.china.huawei.com ([7.185.36.229]) by dggpemm500002.china.huawei.com ([7.185.36.229]) with mapi id 15.01.2176.012; Fri, 11 Jun 2021 17:15:50 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>, Alexander Azimov <a.e.azimov@gmail.com>
CC: "draft-ietf-idr-bgp-open-policy.all@ietf.org" <draft-ietf-idr-bgp-open-policy.all@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt
Thread-Index: AddHqF05jAuFF5QzTsaQPC2aQyKdxQMEUXMAAClIxOACKfzLgABm33fg
Date: Fri, 11 Jun 2021 09:15:50 +0000
Message-ID: <752771c10e0f4a22aa97bd390517ab29@huawei.com>
References: <e45c1b2dcd1a493f9022bb1d9fff40bb@huawei.com> <CAEGSd=ArLeVQy7_p7S5gKfPazFA3Y9-6uzAN-ftogHMK-540cQ@mail.gmail.com>, <5b1c53aa2e9c4a18b03b95fb7b00abf2@huawei.com> <SA1PR09MB814231FB0B10E55ED328557B84369@SA1PR09MB8142.namprd09.prod.outlook.com>
In-Reply-To: <SA1PR09MB814231FB0B10E55ED328557B84369@SA1PR09MB8142.namprd09.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.140]
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/idr/ntgvdADz5XXNR2167HYfKIjSxng>
Subject: Re: [Idr] [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt
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, 11 Jun 2021 09:16:06 -0000

Hi, Sriram

Thanks for the update, it addressed my comments!

Best regards,
Mach

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Sriram, Kotikalapudi (Fed)
> Sent: Thursday, June 10, 2021 12:09 AM
> To: Mach Chen <mach.chen@huawei.com>om>; Alexander Azimov
> <a.e.azimov@gmail.com>
> Cc: draft-ietf-idr-bgp-open-policy.all@ietf.org; idr-chairs@ietf.org;
> rtg-dir@ietf.org; idr@ietf.org
> Subject: Re: [Idr] [RTG-DIR] RtgDir Early review:
> draft-ietf-idr-bgp-open-policy-15.txt
> 
> Hi Mach,
> 
> Thanks for your patience. Alexander and I were able to complete the discussion
> between us.
> 
> Please let us know if the following two proposed changes would adequately
> address your comment:
> 
> We added the following new paragraph in Section 5.1 (just before the OTC
> attribute processing section (Sec. 6)):
> 
>    In the case of a neighbor who doesn't participate, the BGP Role is
>    configured unilaterally based on local knowledge of the peering
>    relationship.  (Note: This applies only to the default non-strict
>    mode; remember that in strict mode, the BGP connection is rejected
>    for any non-participating neighbor.)  The only thing lacking would be
>    a mutual confirmation with the neighbor about BGP Role (this is
>    permissible for backward compatibility in partial deployment).  The
>    OTC attribute processing (Section 6) remains unaffected.
> 
> In the above, if you feel normative language should be used, then we can s/BGP
> Role is configured unilaterally/BGP Role SHOULD be configured unilaterally/.
> Please let us know.
> 
> We made the following old text / new text substitution in Section 8:
> 
> Old text:
>    No Roles SHOULD be configured on a 'complex' BGP session (assuming it
>    is not segregated) and in that case, OTC MUST be set by configuration
>    on a per-prefix basis.  However, there are no built-in measures to
>    check correctness of OTC use if BGP Role is not configured.
> 
> New text:
>    No Roles SHOULD be configured on a 'complex' BGP session (assuming it
>    is not segregated) and in that case, the OTC attribute processing
>    MUST be done relying on configuration on a per-prefix basis.  (Note:
>    The per-prefix configuration of peering relationship is currently
>    done to handle 'complex' BGP sessions.)  However, there are no built-
>    in measures to check the correctness of OTC use if BGP Role is not
>    configured.
> 
> I've attached a diff file that highlights the above-proposed changes and also the
> changes in response to your nits. We'll plan to upload a new version -16 after we
> hear back from you on these proposed changes.
> Thank you.
> 
> Sriram
> ________________________________________
> From: Mach Chen <mach.chen@huawei.com>
> Sent: Saturday, May 29, 2021 4:03 AM
> To: Alexander Azimov
> Cc: draft-ietf-idr-bgp-open-policy.all@ietf.org; idr-chairs@ietf.org; idr@ietf.org;
> rtg-dir@ietf.org
> Subject: RE: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt
> 
> Hi Alexander,
> 
> Please see me response inline with [Mach]
> 
> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alexander Azimov
> Sent: Saturday, May 29, 2021 4:05 AM
> To: Mach Chen <mach.chen@huawei.com>
> Cc: draft-ietf-idr-bgp-open-policy.all@ietf.org; idr-chairs@ietf.org; idr@ietf.org;
> rtg-dir@ietf.org
> Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt
> 
> Dear Mach,
> 
> Thank you for your comments, all nits are already applied.
> 
> [Mach] OK.
> 
> But it proved that different authors have a different reading of your comment
> related to section 6:
> Section 6.
> It does not specify how a speaker handle a route with OTC attribute but the
> sender's role is unknown.
> Are you speaking about the OTC processing in case of the absence of a locally
> configured role?
> Or does it about receiving OTC attribute from a neighbor that doesn't participate
> in the role negotiation?
> 
> [Mach] Actually, in both cases, the role of the peer is uncertain, if so what will the
> ingress policy and egress policy be? For example, regarding ingress policy, how to
> handle a route with OTC attribute but not sure the sender's role. And regarding
> the egress policy, if the peer's role cannot be determined, Whether the route
> should be sent to the peer? Should the OTC be kept?
> 
> Best regards,
> Mach