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

Ketan Talaulikar <ketant.ietf@gmail.com> Wed, 12 April 2023 14:25 UTC

Return-Path: <ketant.ietf@gmail.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 60C90C151B1D; Wed, 12 Apr 2023 07:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.087
X-Spam-Level:
X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 FfON91s7oq46; Wed, 12 Apr 2023 07:25:26 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5150C15155F; Wed, 12 Apr 2023 07:25:26 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id f26so23199730ejb.1; Wed, 12 Apr 2023 07:25:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681309525; x=1683901525; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/CR0ldaSibbEFFFQi4UCnn3HA/uU6gVcuQfUOQsadnU=; b=XpZCwytIFFujJ5Di/egWo2JdKW1jM9Rf6U/hJkkM+43Jx/NOGausDoLtqYSxYJRtB6 9njV67Tp05KtItlZ4yXhibofBWsq7w/+zlKj67axfgI/8OmcwHUaFqy1QI+Jx0HtpvTq mHm634zDuZmNVtKmztvyWWSFsEs6SAlG5v6AD01DIB/CP9CH3zb9BzITaSfhcJF8h5sn 6Vpu+BifwTJAReuic709s19Bfgq7AfuPt++cA01jj7iRspEbHHaLih3p2RK5nGzFgNus TGLhaDcvZvB+nGu7FQVAcdBoMhpuITmwPqUz+mxJA+ojlkAuXgOSDRV1y+Z0aPnd2HpX ku5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681309525; x=1683901525; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/CR0ldaSibbEFFFQi4UCnn3HA/uU6gVcuQfUOQsadnU=; b=MO4QINtqfXOpjxu4r5+i524sxq69dirV1ebEaGK1DFG4h5J6oo0X62FS0wfTYPI5OA kNPn3nrj9sAK6cXiPLdhUvKeEs27c9q2MpCN5KAqh7ciAlXmT3CwBX+2H15CdjV4Oqa3 7Wayi6Y0ohKS8S0tQoQmFQE01UZrkTnEZLuMOohZpGKUmXbeM9DaVFgw8xJ7YzdmhUt6 F14hKeRV/WEacKW3vw6eazCyEMUxbDaMmM1VGeF5aNxmYX+kR+GP1s9ugze1akwx4a7k RCZZ4liBxYJYhUNFcfHfJe1bkDHoYmzaJoQ8cEuvnGG0VWXCi9i/bkhuh/5vq57zb77Q iPyQ==
X-Gm-Message-State: AAQBX9dwGgYPgq6AQpt4Zae7RjYgsbeuh4gCAZkwyl+n8S2nJjq2SjP3 aiYKNcSPLSXpf9mqh9JqMcoBF9tH3foNBsqyND1/9onYcgk=
X-Google-Smtp-Source: AKy350bGpXEp38TS7WBX3QeA4P/Q7WiP9choT9YIYd5FnFEArZbZT9c9bTk7rGqrm0bKl+hQ/Rc1XBzS80snScgNFYk=
X-Received: by 2002:a17:907:7627:b0:94a:7461:e738 with SMTP id jy7-20020a170907762700b0094a7461e738mr5800600ejc.5.1681309524776; Wed, 12 Apr 2023 07:25:24 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <MEYP282MB2942D2A3F89D210C01C9107CFC979@MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Wed, 12 Apr 2023 19:55:11 +0530
Message-ID: <CAH6gdPw2HeWfif8w=d_kqGJio+hPwznnf1k3ju8a+F1nyiQREQ@mail.gmail.com>
To: "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>
Content-Type: multipart/alternative; boundary="000000000000fb599105f92460f6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dInvjR_5hgKj-qLWdNio1VE5W2I>
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: Wed, 12 Apr 2023 14:25:27 -0000

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 <
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
>
>
> *From:* Ketan Talaulikar <ketant.ietf@gmail.com>
> *Date:* 2023-04-06 18:29
> *To:* li_zhenqiang@hotmail.com
> *CC:* draft-ietf-idr-segment-routing-te-policy.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: 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 <
> 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
>>
>>