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

Robert Raszuk <robert@raszuk.net> Thu, 13 April 2023 12:26 UTC

Return-Path: <robert@raszuk.net>
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 B02B9C13AE54 for <idr@ietfa.amsl.com>; Thu, 13 Apr 2023 05:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 0mCgdG5Z8iBb for <idr@ietfa.amsl.com>; Thu, 13 Apr 2023 05:26:33 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 58D81C13AE4D for <idr@ietf.org>; Thu, 13 Apr 2023 05:26:33 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id e16so779827wra.6 for <idr@ietf.org>; Thu, 13 Apr 2023 05:26:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1681388791; x=1683980791; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=loYO59hHBIIv7GAQUA1t/9TshCXB5rm1yGvRYxYukdc=; b=R5r9keW5xf8m4ubs/GyjSpc3OT3B4ROElcxFOBXarTqH6HItaNDB/WF9tIQ4dxSl04 dASVRP1fYMeNZu7wU3er+LJEvt+f6TLrBY/DwvqW5sVmVAo8Y0n41G6xhMp6EN00vXyj t7qF37rThYU7wyo0kefN6SuPBpkOv2W4v0wtQs6yNaftticObpodJiTKfR2Vffyae6V+ yWRwuX3c8J+eIbA13lmmLiaN77eu04VxniXfh1qJ9l1qm6hI/o1JFD4C2pqLOvdPivkM OGsFyOq8HYzUqFFAMB7ND69T2Abcrnbwer5yd2jPjnXVQXQ0fFDU+1QuyXHKHEIA+Jyj qg+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681388791; x=1683980791; 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=loYO59hHBIIv7GAQUA1t/9TshCXB5rm1yGvRYxYukdc=; b=C7TlVjSDPo7iKPYvtojfDzggJFbfoO8UVzKTxhPjxVk7bXCNs8+dT0RAttbgnaOyKQ 7aIoD3k8AdOtQYEd1MmJ0+lNw74KOVPUe8wqWsQiqaHN/k2HTh3Q0EV8Tf0a/VNEOh0b XcVS++WNHht9kNOUIxnk2yj1f6Jq8Qq50WmXH1QmG2JJbXw1LYXnJw4xiGm5vvK7YyM8 7V8tz3VPYxLEzP28LfuUTk4d5oSda0TacCHu+rZaHZihDsuaKSZxqz/kXAwcQTPjb2bw ajuK9pfhaIztcolQVpQGE1a74CAFx7KOT6OI2oVLPj2gYE+1xZ3tSt4k+kkQCCbfjq13 LFqA==
X-Gm-Message-State: AAQBX9eXIqhhja9fjCRC5YJyW3W27nNhTKsTTllGfsToJC5DwGjmdbyk R7ivvIhZKduOxNwv5ydqPOsH3RT72HoCsYhy8oUFfQ==
X-Google-Smtp-Source: AKy350bRBZamVIAj0Gn9LNL4ov65V25Nz9NVAbkrNPZ3R2DsnC1BsX54z6XTgXoJkCQBWwl8SY8km26rbEJamDLHvk0=
X-Received: by 2002:a5d:5225:0:b0:2f5:9146:700f with SMTP id i5-20020a5d5225000000b002f59146700fmr328756wra.11.1681388791239; Thu, 13 Apr 2023 05:26:31 -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> <CAH6gdPw2HeWfif8w=d_kqGJio+hPwznnf1k3ju8a+F1nyiQREQ@mail.gmail.com> <7f1a916911724ee7ad88219394ef7c18@huawei.com> <CAOj+MMH3PKdJ=3mekp+KcN8aQ3k6TYyBdbF6cPpfZCTdTrx6oA@mail.gmail.com> <9093a25e5dfe469ca5345086faf3b831@huawei.com>
In-Reply-To: <9093a25e5dfe469ca5345086faf3b831@huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 13 Apr 2023 14:26:20 +0200
Message-ID: <CAOj+MMGdsfcwUyaMyyWxmBcnLDPV1u+fso48r+dyqQNDYr-YZw@mail.gmail.com>
To: "tanzhen (A)" <tanzhen6=40huawei.com@dmarc.ietf.org>
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="000000000000a1a61a05f936d5fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Sl0Jxzwy7zg8orlc2q50NUBgAvE>
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:26:37 -0000

Hi,

I must disagree.

NLRI format of RTC does not contain those two octets:   | 0x01 or 0x41 |
Sub-Type |

Sorry, R.

On Thu, Apr 13, 2023 at 2:20 PM tanzhen (A) <tanzhen6=
40huawei.com@dmarc.ietf.org> wrote:

> 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> 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.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>