Re: [Idr] Clarifications on draft-ietf-idr-segment-routing-te-policy

"tanzhen (A)" <tanzhen6@huawei.com> Thu, 13 April 2023 12:19 UTC

Return-Path: <tanzhen6@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 11705C15C524; Thu, 13 Apr 2023 05:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWGkiXdckkvz; Thu, 13 Apr 2023 05:19:57 -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 51DDEC15C296; Thu, 13 Apr 2023 05:19:57 -0700 (PDT)
Received: from lhrpeml100005.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4PxzC332LHz67Xv4; Thu, 13 Apr 2023 20:18:55 +0800 (CST)
Received: from kwepemi500014.china.huawei.com (7.221.188.232) by lhrpeml100005.china.huawei.com (7.191.160.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 13 Apr 2023 13:19:53 +0100
Received: from kwepemi500015.china.huawei.com (7.221.188.92) by kwepemi500014.china.huawei.com (7.221.188.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 13 Apr 2023 20:19:51 +0800
Received: from kwepemi500015.china.huawei.com ([7.221.188.92]) by kwepemi500015.china.huawei.com ([7.221.188.92]) with mapi id 15.01.2507.023; Thu, 13 Apr 2023 20:19:51 +0800
From: "tanzhen (A)" <tanzhen6@huawei.com>
To: Robert Raszuk <robert@raszuk.net>
CC: authors <draft-ietf-idr-segment-routing-te-policy.authors@ietf.org>, "idr@ietf.org" <idr@ietf.org>, idr-ads <idr-ads@ietf.org>, idr-chairs <idr-chairs@ietf.org>
Thread-Topic: [Idr] Clarifications on draft-ietf-idr-segment-routing-te-policy
Thread-Index: AQHZabi/31lsQ7MZskaG8Lo1mH7VtK8nwm2rgAE6BDD//31HAIAAjqxw
Date: Thu, 13 Apr 2023 12:19:51 +0000
Message-ID: <9093a25e5dfe469ca5345086faf3b831@huawei.com>
References: <BYAPR08MB4872737894DA7507D4F54C2BB3AD9@BYAPR08MB4872.namprd08.prod.outlook.com> <CAB75xn70k8xE3QaNKqHkHn=22gD0NEG65o1uooB6puNx4xWB6A@mail.gmail.com> <43a2fb5f9f3747ea9c31423d19e332d1@huawei.com> <CAB75xn4Dk7Ge9VAbB9eQ9Pqh+1mzJH0_29OqX-PB40t1sD9H7Q@mail.gmail.com> <ME3P282MB29401E421BAE4C236C86DC18FC919@ME3P282MB2940.AUSP282.PROD.OUTLOOK.COM> <CAH6gdPytvU2w9Fp6DjsnaXBDk9cVvONkptUVQdvusdv7=Mv5Zg@mail.gmail.com> <MEYP282MB2942D2A3F89D210C01C9107CFC979@MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM> <CAH6gdPw2HeWfif8w=d_kqGJio+hPwznnf1k3ju8a+F1nyiQREQ@mail.gmail.com> <7f1a916911724ee7ad88219394ef7c18@huawei.com> <CAOj+MMH3PKdJ=3mekp+KcN8aQ3k6TYyBdbF6cPpfZCTdTrx6oA@mail.gmail.com>
In-Reply-To: <CAOj+MMH3PKdJ=3mekp+KcN8aQ3k6TYyBdbF6cPpfZCTdTrx6oA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.152.185]
Content-Type: multipart/alternative; boundary="_000_9093a25e5dfe469ca5345086faf3b831huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/GTu-d8V8TJ9VqgJSrvnUyw56sh4>
Subject: Re: [Idr] Clarifications on draft-ietf-idr-segment-routing-te-policy
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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, 13 Apr 2023 12:19:59 -0000

Robert,

Thank you for comments.

I believe that this draft should be called an extension of application scenarios of RTC, since it doesn’t violet the concept of RTC. It is written in RFC 4684, Chapter 4 that, I quote below:
“Route targets can then be expressed as prefixes, where, for instance, a prefix would encompass all route target extended communities assigned by a given Global Administrator [6].”
For reference [6], it points to RFC 4360,“BGP Extended Communities Attribute”. And the format and meaning of "IPv4 Address Specific Extended Community" is actually defined in this document, precisely in section 3.2.

We didn't define an incompatible format of NLRI for the same AFI/SAFI. And therefore, this is not broken.

Regards.
Zhen.

From: Robert Raszuk [mailto:robert@raszuk.net]
Sent: Thursday, April 13, 2023 5:24 PM
To: tanzhen (A) <tanzhen6@huawei.com>
Cc: Ketan Talaulikar <ketant.ietf@gmail.com>; li_zhenqiang@hotmail.com; authors <draft-ietf-idr-segment-routing-te-policy.authors@ietf.org>; idr@ietf.org; idr-ads <idr-ads@ietf.org>; idr-chairs <idr-chairs@ietf.org>
Subject: Re: [Idr] Clarifications on draft-ietf-idr-segment-routing-te-policy

Hi,

> https://datatracker.ietf.org/doc/draft-ding-idr-rtc-for-bgp-flow-sr/

I am sorry but this is completely broken.

You can not have different formats of NLRIs for the same AFI/SAFI.

Please do not call this RTC extension as this has nothing to do with RTC.

Route Target is not "IPv4 Address Specific Extended Community"

If you are willing to provide such filtering please use a different name and a different (new) AFI/SAFI.

Regards,
Robert.


On Thu, Apr 13, 2023 at 11:13 AM tanzhen (A) <tanzhen6=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:
Ketan, Zhenqiang Li,

Hi.

We posted a new draft last month, which might be a good way to solve your problem.

In the draft, we proposed to extend the application scenarios of RTC to BGP Flow and BGP SR-Policy for outbound route filtering (ORF). You can find more details here: https://datatracker.ietf.org/doc/draft-ding-idr-rtc-for-bgp-flow-sr/

Looking forward to your comments.

Thank you.