Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)

Gyan Mishra <hayabusagsm@gmail.com> Wed, 03 March 2021 07:11 UTC

Return-Path: <hayabusagsm@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 F07103A1BBB; Tue, 2 Mar 2021 23:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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=gmail.com
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 mWuGlgdVRPZC; Tue, 2 Mar 2021 23:11:16 -0800 (PST)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 1DE3C3A1BB9; Tue, 2 Mar 2021 23:11:16 -0800 (PST)
Received: by mail-pj1-x1031.google.com with SMTP id o6so3744557pjf.5; Tue, 02 Mar 2021 23:11:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OSd9kHcVIXcQDYeuSHiiDxxLQ7Ms2yNejkzFrheQrm0=; b=EhgibjMcS4HRRO8tRrSnnptuwJlkig8M8GBzTIh4FABqfwfO3//Eo+6UB2W3DT8kuZ BXbwumsOOgE06fiPMFyx+BP9VSrOsjWjmb/GoGs7x6EhQOiIvHJpDVlSfS2yzkdOi9Sv 1dOpw+EJsITWzYH+uKevRDXgmDYcQ3+eU7bweb9mCc52/uEbvRFeCrJEJabVLBL0ptvf HiRRkcZ8T6l5Su8+f0aIEAYPrNnkVt5v2w4GFXg4axnY5f8kUVQ0R6nWmfXjnGKhDMiM FCngIxlTeVVVlPtFSSLDqZ6F0el2po4xFIiKUO6lJshWOwVDFMaosK+BfALvYHisLuwv HlKg==
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=OSd9kHcVIXcQDYeuSHiiDxxLQ7Ms2yNejkzFrheQrm0=; b=oIwPK4udZ9kovLjPr0oAO6ElWoy1xjzoEo43mi9pg7TOe4m+QN9aKwY9aOWLrxR5FK zy0hF2iRZn7bBunXvhbpWRUyUb/MylCey7wlGwovp28MYWIi1Mzd0m1i4F4M3yk+0zJN VOIKzVcO7BwaZElqUPZSK+Wh6Unj87kQLreOm1Bng3M5SBa+SxIbm8Ihcx5iuRf1U7x9 U8hpyFlZmfRKbvJ7nwe5i/WEnWCz12yQz8tZHPTpZMVj/j2eexKRMi7K1A5dWdKS44Lq 8au53zrFbEwuflG1creJWbSDJr6OvI5NCeyQdk9bk5KSGoapRS6Oi8FKRttRb4BbS9p9 OE+w==
X-Gm-Message-State: AOAM5316xt3RiDcdJvJkyAR2AZ1FA/KlKGxk1/P1O2Hr2jGxaMEnDGvc IlccUTXOJcBlUIPDUnsk00ocU2TlC/irxAmr3fLwCUwQKC8=
X-Google-Smtp-Source: ABdhPJwTzYVXBc3saPUq27lHwGeoHYlnI2RAxmo4g9nG1ZzivEDkTiETgESikih0PubrFAdcuChR/mWhrHjR1a8i8oQ=
X-Received: by 2002:a17:90a:65c4:: with SMTP id i4mr8180202pjs.132.1614755474482; Tue, 02 Mar 2021 23:11:14 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMFdeajhek99uFi+CU4J6qA1QwWoAA7Wh+tSu2dvXo+hPA@mail.gmail.com> <169FA298-3F52-4A20-94CA-0F89BF8605C7@chinatelecom.cn> <014501d70ffa$181048c0$4830da40$@tsinghua.org.cn>
In-Reply-To: <014501d70ffa$181048c0$4830da40$@tsinghua.org.cn>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 3 Mar 2021 00:15:54 -0500
Message-ID: <CABNhwV2VJgDPwpUAXg+ZNsJ1A-Ba+WOvjTG2iBYbwPFQm18AQQ@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: draft-wang-idr-rd-orf@ietf.org, IDR List <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000074a8cf05bc9c8eab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xw7kyV97L8LM9BAixadVYy_4rGw>
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: Wed, 03 Mar 2021 07:11:20 -0000

Slide deck looks good to present.  All set.

Thanks

Gyan

On Wed, Mar 3, 2021 at 1:54 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:

> Hi, Gyan:
>
>
>
> I have finished the draft of presentation material, which is slightly
> different from the uploaded draft.
>
> Please review it whether it is enough for the presentation. I will update
> the draft accordingly in these days if we have consensus on the
> presentation material.
>
>
>
> We have also discussed also the solution yesterday offline with experts
> from Huawei.  Will update the solution draft after the WG consensus on the
> problem analysis draft.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* idr-bounces@ietf.org <idr-bounces@ietf.org> *On Behalf Of *Aijun
> Wang
> *Sent:* Saturday, February 27, 2021 8:41 AM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* draft-wang-idr-rd-orf@ietf.org; idr@ietf.org
> *Subject:* Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re:
> rd-orf problem clarification at the local level)
>
>
>
> Hi, Robert:
>
> If you use non-transitive attributes, every in-path router must decide and
> add/delete it based on its justification.
>
> If so, why bother RTC and why use the BGP-Update message?
> ORF/Route-refresh message is the right mechanism to utilize.
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Feb 27, 2021, at 08:18, Robert Raszuk <robert@raszuk.net> wrote:
>
> 
>
>
>
> I am not proposing anything new nor change to RTC dynamics or current
> fundamental operation model of RTC.
>
>
>
> RTC NLRIs would be flooded just like today however it is just like with
> some attributes or non transitive at domain border communities that routers
> drop them before propagating over ebgp here we would not propagate by
> default this new attribute. Actually it should be non transitive - I am
> self correcting myself here.
>
>
>
> Here the definition of handling this attribute would be not to propagate
> within it such RDs to other ibgp or ebgp peers unless all requesters
> indicating interest with given RT also signalled such filtering request for
> those RDs. Obviously there should be no need to also propagate such
> attribute with an empty list of RDs.
>
>
>
> Sure as pointed by Jakob when new peer comes up and he sends interest in
> those RT(s) without RD such routes must be sent to him or requested
> upstream. All easily doable if and only if there is real need for it.
>
>
>
> Thx
>
> R.
>
>
>
> On Sat, Feb 27, 2021 at 12:51 AM Aijun Wang <wangaj3@chinatelecom.cn>
> wrote:
>
> Hi, Robert:
>
>
>
> We should keep mind that the message “What I want(expressed by RTC)” can
> be flooded automatically throughout the network, but “What’s I don’t
> want(expressed by RD-ORF)” should not be flooded out unconditionally.
>
> Try to use RTC to express “What I don’t want” within the network(not just
> in one device) will change the RTC mechanism dramatically, not just the
> unrecognized transitive attributes.
>
>
>
> On the contrary, ORF based solutions can cover the situations what RTC
> aimed. Don’t you think so?
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Feb 27, 2021, at 00:28, Robert Raszuk <robert@raszuk.net> wrote:
>
> 
>
>
>
>
>
> 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 Architect *
>
>
>
> *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 Architect *
>
>
>
> *M 301 502-134713101 Columbia Pike *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