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)

Jeffrey Haas <jhaas@pfrc.org> Fri, 21 October 2022 20:13 UTC

Return-Path: <jhaas@pfrc.org>
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 B5087C1522DC for <idr@ietfa.amsl.com>; Fri, 21 Oct 2022 13:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 9uSqADBzrc_V for <idr@ietfa.amsl.com>; Fri, 21 Oct 2022 13:13:33 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBB1C1522A8 for <idr@ietf.org>; Fri, 21 Oct 2022 13:13:32 -0700 (PDT)
Received: from smtpclient.apple (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 3B1C21E039; Fri, 21 Oct 2022 16:13:31 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D34E55F2-8F08-4274-830F-E808F32F997E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CAOj+MMFw+2uTs19jHTOF9kaQRog_m9nW4L+4gLkB0c7k9Mi1+A@mail.gmail.com>
Date: Fri, 21 Oct 2022 16:13:30 -0400
Cc: Randy Bush <randy@psg.com>, Gert Doering <gert@space.net>, idr <idr@ietf.org>, Sue Hares <shares@ndzh.com>, "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>, "Van De Velde, Gunter \\(Nokia - BE/Antwerp\\)" <gunter.van_de_velde@nokia.com>
Message-Id: <9953B13E-DC91-4A10-92E0-317629571656@pfrc.org>
References: <028ECC42-2021-4D00-9B31-B323F2480DAA@gmail.com> <Y0mJ2CJQbUbf6pzO@Space.Net> <20221014182353.GF2066@pfrc.org> <CAOj+MMGr3X58yCoR9uLXmoNUtk4b+=00o2JB9tEKpENTU6M6Yw@mail.gmail.com> <20221019214126.GB10497@pfrc.org> <CAOj+MMHafWNKaDBfcvdVKz7RoX4eFxkk2KjVvqN9vS=2+vNeGw@mail.gmail.com> <20221019222746.GD10497@pfrc.org> <CAOj+MMEstWKm+xoWBRFJjJW-vhX_4BKerWCt94GiQT+W5tELPA@mail.gmail.com> <20221020204232.GD19035@pfrc.org> <CAOj+MMFAkrq4bTyx-Gf4ivfBetnaH0bSJo34wmyXwXL5nQEWxg@mail.gmail.com> <20221020210047.GA25483@pfrc.org> <CAOj+MMHtk5hJ17K_7e5MjGLxKbTP2mCoAZ0z085PV+5VzmaPrw@mail.gmail.com> <m28rl9dvsn.wl-randy@psg.com> <0D810195-CFC6-43C6-84F7-609CAA4B3C7F@pfrc.org> <CAOj+MMFw+2uTs19jHTOF9kaQRog_m9nW4L+4gLkB0c7k9Mi1+A@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TeSRamOJH40j0lVqoqFhkw6ZoGA>
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: Fri, 21 Oct 2022 20:13:36 -0000


> On Oct 21, 2022, at 12:27 PM, Robert Raszuk <robert@raszuk.net> wrote:
> 
>  
> Perhaps Robert will share whose implementation is intentionally broken in this fashion to help shortcut that process.
> 
> I do not consider implementation to be broken the moment IDR decides to use BGP as point to point configuration protocol and forces it to filter BGP UPDATES from arbitrary AFI/SAFI when propagating towards IBGP peers. 
> 
> For current SAFIs with unique RDs and RT based filtering nothing is broken.

A peers with B with RT-C and L3VPN.
B advertises to A an RT-C route that attracts route-target:100:100

A theoretically filters L3VPN routes at the update-send portion of the process by dropping updates containing no matching RT-C extended communities of interest.

A advertises L3VPN route RD:prefix to B with route-target:100:100 and route-target:200:200.  This matches received RT-C for route-target:100:100 from B and is thus transmitted.

A has a properties change for the route and needs to advertise L3VPN route RD:prefix to B with only route-target:200:200.
There is no matching received RT-C route from B with this route-target.  

If the route is filtered, B now has stale state.

If A doesn't generate a withdraw for this route, B now has stale state.

Q.E.D.

-- Jeff

v2.23.0 | Report a Bug | By Email