Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)
Robert Raszuk <robert@raszuk.net> Fri, 26 February 2021 16:28 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 E16633A0F49 for <idr@ietfa.amsl.com>; Fri, 26 Feb 2021 08:28:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUA89sCWt7-g for <idr@ietfa.amsl.com>; Fri, 26 Feb 2021 08:28:08 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72083A0F44 for <idr@ietf.org>; Fri, 26 Feb 2021 08:28:07 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id a17so11283107ljq.2 for <idr@ietf.org>; Fri, 26 Feb 2021 08:28:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wogay6Jb4otGgRKymO7E6Vlefivf01/NA9qq8E65wZw=; b=WyhIklN/MtdaIQrV7DyeaEvEw396/rXmCQpdo036d0EN7wjaTM9+U5+EV2qYmpd3Z0 lRN28YEn7aCcGvgOQHWD4v0qn5/bIufFBudhMF0yiE7PAcHX231ryX5toCHxR2DMFBnR 0cUGBSx1GKLa7MHdKzws+4FCLqtnD5Y8dOUvW27U+r6f2ImcYpE9LUbsKverBcjJQ57R VqZ6voHNGHjPvMyQxW7iYYxSQehKtCnyGvFtl9c29wHcgPyRlFlEDACqBCP0uCPEGw5G T4G+2TAsglFO4uVgVwF2kqaJxLk+MmMYnpOQCmqwX+/+OEQu8UGlBsYtHDLiLQ1admSH 8X3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wogay6Jb4otGgRKymO7E6Vlefivf01/NA9qq8E65wZw=; b=m23E0pKioferv2RzH0Kid0FM94vKxNGieASFJDTXn7OOtp1PYZIZs00w9oMrvhz+ni 7/+2MK1sOxNsMoyCR0bt2yspfDk4erSlvxf1EgpO5jZAfmrC7xFshlV9IarxuUNLe8o0 91Wz+wsCwuXqt/r/X65iWv0nQoUK77iqfUOcGNg/KPJtBAU/PiCzvitmPVvOQHII28cE XzYm+nAwE0bWZy6vCt9+JgGXbWCv7Ycz+ph8gy4qQzzhqUrfJPC7ykurmSUYQgPyk1bq d990e+KKKhSb/9z1QQ1rLQlchBJnVhTqkvrPJ8SPqRgCipSr2Rg2Ae2DVitaU1WAK8m2 257w==
X-Gm-Message-State: AOAM5315tk4SGrJVUGI/hCJCRjxAD9xP+Tkd6yGgd5OxU2odSiUnGuPn yvLTXYAw0eb9qK71LIgoXI9boe0V/2x59sLS9fQaxQ==
X-Google-Smtp-Source: ABdhPJwi12eJuFlKmz0iJpS7QJu8Uzj+jz+20aK9goayJhn3H4TjgV67+IcRTRTIElxHv23ROnPkuc3CZwcbGasIKoI=
X-Received: by 2002:a2e:330d:: with SMTP id d13mr2105346ljc.361.1614356885771; Fri, 26 Feb 2021 08:28:05 -0800 (PST)
MIME-Version: 1.0
References: <20210225142155.GA27005@pfrc.org> <A7C19F05-DBCD-4AA8-ADC9-7F608BA9F540@chinatelecom.cn> <CABNhwV0EeUt-aue74xK9jAO-9MJXuj6kzNegwyC=d5o3Wd6aXA@mail.gmail.com> <CAOj+MMGgY198Z4Uz8NBDMDMYtinBCauxtPxEojzhiQekJwOYaw@mail.gmail.com> <CABNhwV0EZ2Au-W4-yxKuRV6CstVB4nk-FqCBOag4XkGR=RnZqQ@mail.gmail.com>
In-Reply-To: <CABNhwV0EZ2Au-W4-yxKuRV6CstVB4nk-FqCBOag4XkGR=RnZqQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 26 Feb 2021 17:27:55 +0100
Message-ID: <CAOj+MMFMdAL=b2WprdGnpuZEXbJkcsR__XuDnwRP5LYu-00PDw@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Aijun Wang <wangaj3@chinatelecom.cn>, draft-wang-idr-rd-orf@ietf.org, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b7aab705bc3fc01c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_yPOGrWAR4F1BN69JcbjYoA-EaU>
Subject: Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 26 Feb 2021 16:28:11 -0000
On Fri, Feb 26, 2021 at 4:49 PM Gyan Mishra <hayabusagsm@gmail.com> wrote: > > Hi Robert > > In the first comment in the thread as a requirement to identify the > Prefixes based on RD to be blocked in the case of not unique RD requires an > AND of both RD+RT in the logic. I am in complete agreement that is > required. > > So I can see Jeffrey’s idea as a possible solution to modify RTC to > include offending RD update to RTC spec. > Just to be clear ... Jeff did not suggest that. This suggestion I wrote. > However, the RD ORF uses existing ORF machinery with add of new ORF type > which to me seems a very minor change. The nice thing about RD ORF is that > it is controlled and requires manual intervention to unblock where RTC > would be automatic and that could cause undesirable instability. > That can be manual even for RTC. Consider advertising an RD attribute as a static route. It will be advertised till operator removes it. > I am not sure if modifying RTC to include RD block logic would not cause > added instability with RTC as RTC acts only on RT, as I this is a > significant change to RTC membership logic. Also any existing > implementation of RTC would all be impacted by this change. With RD ORF as > this is a new type ORF, the ORF policy would have to be explicitly defined > so this would only effect new deployments wanting to take advantage of RD > ORF granularity of filtering. > The attribute wouild be optional transitive attribute. If you do not recognize you do not use it. Thx, R. > > Gyan > > On Fri, Feb 26, 2021 at 5:47 AM Robert Raszuk <robert@raszuk.net> wrote: > >> Gyan, >> >> What you said is pretty obvious I think to everyone here. >> >> But I think the point of bringing RTC into this picture was a bit >> different. >> >> Just imagine RTC is running between PE and RR and signals interest in set >> of RTs to the RR. Let's say those RTs are RT100, RT200, RT300, RT400, RT500 >> >> Further imagine one VRF importing RT200 overflows on said PE with >> incoming (pre-import routes of RD_FOO and RT100, RT200 and RT 300). >> >> So what if now PE via RTC will simply readvertise interest to get RT200 >> with new BGP attribute say called BLOCK_RD and lists in such attribute body >> Route Distinguisher of RD_FOO ? >> >> The overall mission accomplished. No need for any new ORF type. It can be >> even transitive if we apply a little hack and adjust the way RR will select >> the best path for RTC (meaning include this attribute in advertisements >> only if all peers sending RT200 attached it with such RD_FOO). >> >> To me this is very simply RTC extension and it seems solves this entire >> "problem". >> >> And no - by proposing the above I am not changing my mind that it is >> simply wrong network operation to even allow such problem to happen in the >> first place. >> >> Best, >> R. >> >> >> On Fri, Feb 26, 2021 at 4:52 AM Gyan Mishra <hayabusagsm@gmail.com> >> wrote: >> >>> >>> Hi Jeff >>> >>> Keep in mind that RTC is an optimization that does not apply to every >>> scenario especially in cases where all PEs have all the same VPNs defined >>> with explicit RT import. The special cases were RTC does apply is for >>> incongruent VRFs in cases of a sparse RT distribution graph where PEs don’t >>> all import the same RTs. By default all PE have RT filtering enabled by >>> default meaning if their is not an explicit VRF definition to match and >>> import the RT, the RT is dropped. With RTC the distribution graph of what >>> RTs are advertised RR-PE is now optimized with RT membership, and now only >>> RTs explicitly imported by the PEs are now advertised by the RR to PE for >>> processing. In the case of RD-ORF, it provides a layer of needed >>> granularity as the RD PE originator of the flood is a subset of all the VPN >>> prefixes represented by the RT permitted by RTC to be advertised to the >>> PE. The RD-ORF now dynamically blocks the offending PE prefixes that would >>> otherwise have been advertised by RTC RR to PE and accepted by the PE for >>> processing and added to the VRF RIB being overloaded. >>> >>> >>> Kind Regards >>> >>> Gyan >>> >>> On Thu, Feb 25, 2021 at 6:21 PM Aijun Wang <wangaj3@chinatelecom.cn> >>> wrote: >>> >>>> Hi, Jeff: >>>> Thanks for your suggestions! >>>> I think combine RTC and RD-ORF information can accomplish the fine >>>> control for the upstream propagation of unwanted VPN routes. >>>> We will also try to find other ways to achieve the same effect. >>>> >>>> Aijun Wang >>>> China Telecom >>>> >>>> > On Feb 25, 2021, at 22:01, Jeffrey Haas <jhaas@pfrc.org> wrote: >>>> > >>>> > Aijun, >>>> > >>>> > On Thu, Feb 25, 2021 at 12:07:49PM +0800, Aijun Wang wrote: >>>> >>> In the prior discussions, it was clear that remediation was trying >>>> to be >>>> >>> done on a per-RD basis. The text in this draft seems to be a >>>> larger scope >>>> >>> than that; perhaps per VPN (and thus route-target?). Is that your >>>> >>> intention? >>>> >> [WAJ] Yes. We are considering to add RT information to the current >>>> RD-ORF >>>> >> semantic, to identify/control the "excessive routes" in more >>>> granular. >>>> > >>>> > Thanks for the clarification. That expands the scope of the original >>>> > discussion, but might be helpful for the solution. >>>> > >>>> >>> For a route reflector, it would require that all possible receivers >>>> for a >>>> >>> RD/RT have no interest in the routes, and that the source of the >>>> routes is >>>> >>> clearly directional. BGP does not provide such a distribution >>>> graph. >>>> >> >>>> >> [WAJ] " all its downstream BGP peers can't or don't want to process >>>> it" >>>> >> means RR receives the RD-ORF messages for the same set of VPN routes >>>> from >>>> >> all of its clients. This can be achieved by RR >>>> > >>>> > For my point, consider a trivial case: >>>> > >>>> > PE1 --- RR --- PE2 >>>> > >>>> > PE2 is the source of the excess routes. >>>> > PE1 is the impacted router. >>>> > RR has only PE1 and PE2 as peers. >>>> > >>>> > By your current text, RR can only do something if PE1 and PE2 say >>>> they're >>>> > not interested. >>>> > >>>> > It can be observed here that if we have exactly one peer left, we >>>> could >>>> > signal to that one peer. >>>> > >>>> > I suspect your intent is to cover situations where you can >>>> distinguish PE >>>> > routers from solely internal route distributuion infrastructure, such >>>> as >>>> > route reflectors. So, using a slighly more interesting topology: >>>> > >>>> > PE1 --- RR1 --- RR2 --- PE2 >>>> > >>>> > PE2 is the source of the excess routes. >>>> > PE1 is the impacted router. >>>> > RR1 has only PE1 as a PE device. >>>> > >>>> > If PE1 signals to RR1 that it isn't interested in the offending >>>> routes, RR1 >>>> > may propagate the filter. >>>> > >>>> > The issue here is that BGP does not specifically distinguish whether >>>> an >>>> > attached BGP Speaker is a PE or not. The protocol doesn't help you >>>> make >>>> > this determination. >>>> > >>>> >>> In a network using RT-Constrain without a default RT-Constrain >>>> route, such a >>>> >>> graph potentially exists. >>>> >> [WAJ] RT-Constrain can only express explicitly "what I want" and the >>>> >> distributed graph. It can't express explicitly "what I don't want" >>>> now, also >>>> >> the distribution-block graph. Is that right? >>>> > >>>> > That is correct. But consider the following example: >>>> > >>>> > PE3 >>>> > | >>>> > PE1 --- RR1 --- RR2 --- PE2 >>>> > >>>> > PE2 is the source of the excess routes for VPN RT-A. >>>> > PE1 is the impacted router. >>>> > RR1 has PE1 and PE3 as attached PE routers. >>>> > All routers are configured to use RT-Constrain >>>> > PE1 and PE2 source RT-Constrain routes for RT-A. PE3 does not. >>>> > >>>> > If PE1 signals to RR1 that it isn't interested in the offending >>>> routes, and >>>> > that signal not only includes the offending RD, but also the matching >>>> RTs, >>>> > RR1 can determine that there are no further interested receivers for >>>> that >>>> > RD+RT and propagate that to RR2. >>>> > >>>> > RT-Constrain provides the ability to figure out what the interested >>>> > receivers are for a VPN defined by a route-target. This provides a >>>> > restricted subset of the attached routers for propagation purposes. >>>> > >>>> > -- Jeff >>>> > >>>> >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr >>>> >>> -- >>> >>> <http://www.verizon.com/> >>> >>> *Gyan Mishra* >>> >>> *Network Solutions A**rchitect * >>> >>> >>> >>> *M 301 502-134713101 Columbia Pike >>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver >>> Spring, MD >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > >
- [Idr] rd-orf problem clarification at the local l… Jeffrey Haas
- Re: [Idr] rd-orf problem clarification at the loc… Robert Raszuk
- Re: [Idr] rd-orf problem clarification at the loc… Aijun Wang
- Re: [Idr] rd-orf problem clarification at the loc… Aijun Wang
- Re: [Idr] rd-orf problem clarification at the loc… Jeffrey Haas
- [Idr] draft-wang-idr-vpn-routes-control-analysis … Jeffrey Haas
- Re: [Idr] rd-orf problem clarification at the loc… Aijun Wang
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Aijun Wang
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Jeffrey Haas
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Aijun Wang
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Gyan Mishra
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Robert Raszuk
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Aijun Wang
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Robert Raszuk
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Gyan Mishra
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Robert Raszuk
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Jeffrey Haas
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Jeffrey Haas
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Gyan Mishra
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Robert Raszuk
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Aijun Wang
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Gyan Mishra
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Aijun Wang
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Robert Raszuk
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Robert Raszuk
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Aijun Wang
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Aijun Wang
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Gyan Mishra
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Aijun Wang
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Susan Hares
- Re: [Idr] draft-wang-idr-vpn-routes-control-analy… Aijun Wang