IETF Logo Mail Archive

Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

Robert Raszuk <robert@raszuk.net> Sat, 08 October 2022 07:51 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 5367BC1524AA for <idr@ietfa.amsl.com>; Sat, 8 Oct 2022 00:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 XNAkoB6TKVd9 for <idr@ietfa.amsl.com>; Sat, 8 Oct 2022 00:51:25 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 43A3AC14F730 for <idr@ietf.org>; Sat, 8 Oct 2022 00:51:25 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id f11so10184296wrm.6 for <idr@ietf.org>; Sat, 08 Oct 2022 00:51:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Pwgn5pqN0MqNtVVSSas5xX/3Hh6sWgCSY8K8SesTShc=; b=eVfsbdbga5C55nwwD2Ox4NRahgTWzeqTOdtwghDJzhTJKh2iOnPXYsNDIvpt4ic+3J ucsBg3YvrW7JMdpRXKxRqHOq4WNXmS7HlIHlZq8ObECQe972ddfskd8ekaTNLbKfPS9W rmx0Z87CG4bTI4C7NpCp/pe+skTaDAYKbD2Mth546z3FYISZWi07DJg76SYXgBudA08Z foVlIK0JnSHCHLvAJFGwGmHTnTjX95wGNKAgZtNwVmVeb/naoEIX2PqeUD+7F6DGne37 mXBMRY42vK7wvn4o2EJrqzbQffyrdRdQn6M8BQEqpmC34+HjkMukJezWtsldutmOx4rB rNiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Pwgn5pqN0MqNtVVSSas5xX/3Hh6sWgCSY8K8SesTShc=; b=V8P4IrrAYoXnN3hJpEW0SUNlp2wEa9ACAnPtmwk8oFIqNb08joOEsuBFWk2wZZO8VZ uEKf8fcF8SSyqKRW7+HY+YJNEfABr5rDLtPxeQ0OQoCl+4XgGkj07HRwLZqZzXmaLddj SQ9971k4qEyiI29pTzd7iBotW8k7VKFhTBh0MO2g2ei6KLg2D5lwASLaia0QVwDHMEz3 RHY8CMsMCt0mIDnhd8EGjfdr83PsKXgpKuxyZSdii+A6zpb3/9eeZSnEQkWmC05s4D0y 26fTQbshvuA2iYDgFUBaG3VC3IrPWbBL3vDG1ekc7Z3KWbZ0p/s6JEzkhvqqYIVydIyU FtWw==
X-Gm-Message-State: ACrzQf3EsB923q6Kgcu5BLelcknBDfQhqimtQcwOdkWy9mW+SgUW8Zca 4umvfadY918a7y31xFf7i1s4Y461Yn5CFbPCtlVy2w==
X-Google-Smtp-Source: AMsMyM7/jh0yUnItY9uJw1su3z5ifIEmFD7cprRuUEgRRPKawvV7TrXeJynRl5/UI2ZkN63vNNmrn+GYnaN15icz/EA=
X-Received: by 2002:a5d:47a1:0:b0:22e:7507:a1ab with SMTP id 1-20020a5d47a1000000b0022e7507a1abmr5516111wrb.230.1665215483475; Sat, 08 Oct 2022 00:51:23 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR08MB4872EEE329BDDDCC0F387B17B3559@BYAPR08MB4872.namprd08.prod.outlook.com> <c76e223fd52942e7b8b2924f1de340c6@huawei.com>
In-Reply-To: <c76e223fd52942e7b8b2924f1de340c6@huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 08 Oct 2022 09:52:01 +0200
Message-ID: <CAOj+MMGpfAyQsJPM4fRf5D+wKgR9jqr3GD6Rwgc1ATHQnF9v1Q@mail.gmail.com>
To: "Wanghaibo (Rainsword)" <rainsword.wang=40huawei.com@dmarc.ietf.org>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
Content-Type: multipart/alternative; boundary="0000000000005e0c3405ea8131d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/T1v7Fyfrk7g9yS8W8sAkKWmRT38>
Subject: Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)
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: Sat, 08 Oct 2022 07:51:29 -0000

Haibo,

> .. directly filtering the receiver based on the RT.
> However, this method is not applicable to some old address families, such
as Flowspec.

That is incorrect.

Since day one of RFC5575 - FlowSpec uses RT to filter it's UPDATEs. Please
see description for SAFI 134. It is also RTC compatible.

Note that RT filtering can also be applied to SAFI 133.

Thx,
Robert.


On Sat, Oct 8, 2022 at 4:28 AM Wanghaibo (Rainsword) <rainsword.wang=
40huawei.com@dmarc.ietf.org> wrote:

> Hi Sue and WG,
>
>
>
> I support the adoption of this draft.
>
>
>
> Currently, more and more information is delivered by using the extended
> BGP address family through the controller.
>
> Different from traditional BGP flooding, this mode requires filtering at
> the receive end. For example, the SR-Policy defines the method of directly
> filtering the receiver based on the RT.
>
> However, this method is not applicable to some old address families, such
> as Flowspec. Therefore, it is necessary to introduce a common filtering
> mechanism at the receive end.
>
>
>
> Best Regards,
>
> Haibo
>
>
>
> *From:* Susan Hares [mailto:shares@ndzh.com]
> *Sent:* Wednesday, September 28, 2022 1:30 AM
> *To:* idr@ietf.org
> *Cc:* Dongjie (Jimmy) <jie.dong@huawei.com>; Van De Velde, Gunter (Nokia
> - BE/Antwerp) <gunter.van_de_velde@nokia.com>; Zhuangshunwan <
> zhuangshunwan@huawei.com>
> *Subject:* draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and
> IPR call (9/27 to 10/11/2022)
>
>
>
> This begins a 2 week WG adoption and IPR call for
> draft-dong-idr-node-target-ext-comm-05.txt.
>
> https://datatracker.ietf.org/doc/draft-dong-idr-node-target-ext-comm/
>
>
>
> The authors should respond to this email with an IPR statement.
>
>
>
> The WG should consider in their discussion:
>
> 1) Will this new  transitive extended community help
>
> in operational networks?
>
>
>
> 2) What conflicts does this new Extended Community have
>
> with other functions in general BGP route distribution or
>
> VPNs (EVPN, IPVPN)?
>
>
>
> 3) do you have any concern about the text in the draft?
>
>
>
> Cheerily, Sue
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

v2.23.0 | Report a Bug | By Email