Re: [Idr] Clarifications on draft-ietf-idr-segment-routing-te-policy
"tanzhen (A)" <tanzhen6@huawei.com> Thu, 13 April 2023 09:13 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 D32ABC15C294; Thu, 13 Apr 2023 02:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 34Qm7aAsCBRV; Thu, 13 Apr 2023 02:12:58 -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 126B8C15C287; Thu, 13 Apr 2023 02:12:58 -0700 (PDT)
Received: from lhrpeml100003.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4PxtzL45k3z67KmG; Thu, 13 Apr 2023 17:08:30 +0800 (CST)
Received: from kwepemi100009.china.huawei.com (7.221.188.242) by lhrpeml100003.china.huawei.com (7.191.160.210) 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 10:12:53 +0100
Received: from kwepemi500015.china.huawei.com (7.221.188.92) by kwepemi100009.china.huawei.com (7.221.188.242) 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 17:12:52 +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 17:12:52 +0800
From: "tanzhen (A)" <tanzhen6@huawei.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>, "li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com>
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/31lsQ7MZskaG8Lo1mH7VtK8nwm2rgAE6BDA=
Date: Thu, 13 Apr 2023 09:12:51 +0000
Message-ID: <7f1a916911724ee7ad88219394ef7c18@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>
In-Reply-To: <CAH6gdPw2HeWfif8w=d_kqGJio+hPwznnf1k3ju8a+F1nyiQREQ@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_7f1a916911724ee7ad88219394ef7c18huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7IZy5CcyWlC8ocBear8Jky1BlcI>
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 09:13:03 -0000
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. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar Sent: Wednesday, April 12, 2023 10:25 PM To: li_zhenqiang@hotmail.com Cc: 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 Zhenqiang Li, The deployment design that you describe can achieve the optimization that you desire by using outbound route policy on the RR to each of its neighbors. The spec does not prevent an implementation from providing a policy knob to achieve the behavior you desire. Also, consider a deployment design with hierarchical RRs. Would your proposed change not break BGP propagation? Personally, I do not think we should change the base BGP propagation mechanism for such scenarios. BGP is basically a p2mp distribution protocol and we need to be careful how far we bend it for other purposes. Thanks, Ketan On Sat, Apr 8, 2023 at 6:51 AM li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com> <li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>> wrote: Hello Ketan, I understand the objective and the current text do satisfy the objective. What I point out is the issue the objective has and the current text should be refined. suppose a RR has 100 peers, and 10 SR policies are to be configured on each peer. Follow the current text, RR will reflect 1000 SR policies to each peer and only 1% is needed. ________________________________ Best Regards, Zhenqiang Li li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com> From: Ketan Talaulikar<mailto:ketant.ietf@gmail.com> Date: 2023-04-06 18:29 To: li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com> CC: draft-ietf-idr-segment-routing-te-policy.authors<mailto:draft-ietf-idr-segment-routing-te-policy.authors@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>; idr-ads<mailto:idr-ads@ietf.org>; idr-chairs<mailto:idr-chairs@ietf.org> Subject: Re: Clarifications on draft-ietf-idr-segment-routing-te-policy Hi Zhenqiang Li, The objective was not to change the base BGP decision process or the BGP propagation rules for this SAFI. I hope that explains the current text. Thanks, Ketan On Thu, Apr 6, 2023 at 1:53 PM li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com> <li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>> wrote: Hello authors and all, Hope it is not too late to make clarifications on this draft. This draft says one or more IPv4 address format route target extended community attached to the SR Policy advertisement and that indicates the intended headend of such an SR Policy advertisement. And a BGP node advertises a received SR Policy NLRI to its IBGP neighbors according to normal IBGP propagation rules. Here a BGP node can be a RR(Route Reflector) which will reflect all the SR Policies to its IBGP peers regardless of the route target attached to the policies. So the IBGP peer node as the headend will receive lots of policies that are not intended for it because those policies have no route target that indicates the received peer node. In my opinion, the rules for RR to reflect SR policy with route target SHOULD be enhanced. RR SHOULD reflect related policies to relevant peers according to the route target attached to the policies. ________________________________ Best Regards, Zhenqiang Li li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>
- [Idr] Adoption call for - draft-dong-idr-sr-polic… Susan Hares
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Huzhibo
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Zhuangshunwan
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Dongjie (Jimmy)
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… 庞冉(联通集团本部)
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Giuseppe Fioccola
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Chongfeng Xie
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… peng.shaofu
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… duzongpeng@foxmail.com
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Zhangka
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Gyan Mishra
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Dhruv Dhody
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Dongjie (Jimmy)
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Dhruv Dhody
- [Idr] Clarifications on draft-ietf-idr-segment-ro… li_zhenqiang@hotmail.com
- Re: [Idr] Clarifications on draft-ietf-idr-segmen… Ketan Talaulikar
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Boris Hassanov
- Re: [Idr] Clarifications on draft-ietf-idr-segmen… li_zhenqiang@hotmail.com
- Re: [Idr] Clarifications on draft-ietf-idr-segmen… Ketan Talaulikar
- Re: [Idr] Clarifications on draft-ietf-idr-segmen… tanzhen (A)
- Re: [Idr] Clarifications on draft-ietf-idr-segmen… Robert Raszuk
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Dongjie (Jimmy)
- Re: [Idr] Adoption call for - draft-dong-idr-sr-p… Dongjie (Jimmy)
- Re: [Idr] Clarifications on draft-ietf-idr-segmen… tanzhen (A)
- Re: [Idr] Clarifications on draft-ietf-idr-segmen… Robert Raszuk
- Re: [Idr] Clarifications on draft-ietf-idr-segmen… li_zhenqiang@hotmail.com