Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Hi Jim

Comments below that may help explain the gap and problem this draft solves.

BGP peer Maximum prefix can be used to limit prefixes accepted by PE on a
PE-CE *peer to help with overwhelming a VRF in theory.  The problem with
maximum prefix is it is hard to set a limit on the maximum due to resources
statistical multiplexing that all PE-CE links  of VPNs won’t flood
simultaneously thus maximum prefix is either set very high or not set at
all.*

VRF maximum prefix can be used as well to control resource exhaustion on a
PE.  However when the VRF maximum is reached and prefixes are clipped and
dropped from the RIB their is CPU processing impact.   On the flip side - T*he
problem with VRF maximum prefix as well is it is hard to set a limit on the
maximum due to resources statistical multiplexing high customer SLAs that
all VPNs won’t flood and overflow simultaneously the ** maximum prefix is
set very high for customer SLA and as a result could still result in
resource exhaustion on the PE,*

RD Discussion:

The main purpose of the RD is to provide uniqueness to a prefixes imported
into a VRF.
RD also provides the ability to have all paths to be reflected by the RR
using unique RD.  Also unique RD allows for load balancing.  Non unique RD
is a very rare deployment and in general is not used on all PEs that import
prefixes for a VRF as that prevents the RR from advertising all unique
paths for the same prefix redundant paths, resulting in all paths being
reflected to the PEs to not be reflected to other PEs breaking redundancy.

The general best practice by all operators is to use a unique RD per PE
that is importing prefixes for a VRF for redundancy if redundancy exists in
the topology with multiple exit points multi homed CEs.

As per the best practice rule of thumb RD type 1, 6 byte extended community
X:Y value is used which is a 4 byte IP:2 byte AS which can be accomplished
with Auto RD feature which sets the X value to 4 byte IP to the router
loopback and Y value to sequence number digit that increments 0-65535 for
each VRF defined on the PE.

So when RD Auto is used each PE has a unique RD within the same VPN and for
each VPN the Y value is incremented so the RD is unique per VPN on a PE as
well.

RFC 4684 RTC is an optimization used for incongruent VRFs defined on PEs
where all PEs don’t have the same set of VPNs or VRFs defined.
By Default - all PEs have RT filtering enabled by Default so if a PE does
not have an explicit import of an RT the PE will automatically drop all RTs
not explicitly imported called “RT Filtering”.

RTC uses a concept of VRF membership advertisement sent by PE to RR to tell
the RR what VRFs it is a member of so that only those interesting RTs are
sent by the RR reflected to the PE.  RTC filters on uninteresting VRFs RTs
that would get dropped anyway and does not filter on interesting VRF or RT
as the interesting VRF is part of the VRF membership and that is allowed
and not filtered.

So what this does is save on RR to PE reflection of all RTs waste of
bandwidth and so not the RTs of interest to the PE but the uninteresting
RTs which result in being dropped.

As RTC is a RR to PE reflection optimization it is completely orthogonal
and not related to prevention method of VRF overloading issue.

So if a PE VRF is overflowing we cannot filter prefixes based on RT for the
overflowing VRF as that would filter all routes.  We need a a better
granularity in filtering.

So with RD ORF the idea is that to prevent VRF VPN overflow on a PE that
now if a rouge offending  PE is overflowing sending flood of prefixes
causing other PEs to overflow we can now filter that PE for that particular
VPN or VPN causing the overflow by filtering on the PE RD originator of the
VRF prefixes using the Type 1 RD ORF filter.  I mention type 1 RD as that
is the most common.  Any RD type can be used as long as unique.

As pertains to this draft we may want to update and say that the RD has to
be unique on each PE and cannot use a non unique RD as the RD ORF filter
would act like an RT import block and drop all routes.

On Wed, Feb 10, 2021 at 10:02 AM UTTARO, JAMES <ju1738@att.com> wrote:

> *TBH looks like a solution in search of a problem. *
>
>
>
> *The tools used for the last 20+ yrs. to prevent a mis-behaving CE or peer
> are proven. *
>
>
>
> *An example:*
>
>
>
> *“When the VRF of VPN1 in PE1 overflows, due to PE1 and other PEs are*
>
> *   not iBGP neighbors, BGP Maximum Prefix Features cannot work, so the*
>
> *   problem on PE2 cannot be known.”*
>
>
>
> *My take on this very first premise is that a VRF ( VPN1 ) on PE1 is being
> overwhelmed with routes. These routes are not coming from the RR topology.
> So what is the scenario ? Is it a redistribution from VRF ( VPN2 )->VRF(
> VPN1 )? If so, you have a serious security issue.. Is it redistribute from
> another protocol, the GRT? *
>
>
>
> *I disagree with your premise that the current suite of mitigations are
> not sufficient..  There are certain assertions which are subjective and not
> appropriate. AN example:*
>
>
>
> *“4) Configure the Maximum Prefix for each VRF on edge nodes*
>
>
>
> *   When a VRF overflows, it stops the import of routes and log the extra*
>
> *   VPN routes into its RIB.  However, PEs should parse the BGP updates.*
>
> *   These processes will cost CPU cycles and further burden the*
>
> *   overflowing PE.”*
>
>
>
> *What does this mean? There are networks that have been parsing millions
> of BGP Updates and routes. I have seen VRF overflows and they have been
> specific to said customer’s VRF. Where are you coming up with this and
> other broad assertions.*
>
>
>
> *From a solution point of view I do not believe in overloading the object.
> IOW RD is meant to convey uniqueness of a given path through a topology,
> overloading it with this semantic means what to the existing semantic.. As
> an ex, some operators use unique RD so there is no path hiding, eibgp load
> balancing etc.. Generally speaking I do not want my RRs making a best path
> decision for a given path. Some do not use unique RD for there own reasons
> including scale, possible alignment of RR topology to underlying best path
> etc…*
>
>
>
> *In order to use this technology what are the requirements in terms of
> assigning RDs? *
>
>
>
> *Thanks,*
>
> *              Jim Uttaro*
>
>
>
>
>
>
>
>
>
> *From:* Aijun Wang <wangaijun@tsinghua.org.cn>
> *Sent:* Wednesday, February 10, 2021 9:17 AM
> *To:* UTTARO, JAMES <ju1738@att.com>
> *Cc:* Lizhenbin <lizhenbin@huawei.com>; Susan Hares <shares@ndzh.com>;
> idr@ietf.org
> *Subject:* Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt
> (2/4/2021 to 2/18/2021)
>
>
>
> Hi, Jim:
>
>
>
> Would you like to elaborate your considerations in detail?
>
> We can try to address your concerns via the mail list or updating the
> draft if you have reasonable comments.
>
>
>
> Thanks in advance.
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Feb 10, 2021, at 20:35, UTTARO, JAMES <ju1738@att.com> wrote:
>
> 
>
> *Do Not Support.*
>
>
>
> *Thanks,*
>
> *              Jim Uttaro*
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Lizhenbin
> *Sent:* Wednesday, February 10, 2021 4:47 AM
> *To:* Susan Hares <shares@ndzh.com>; idr@ietf.org
> *Subject:* Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt
> (2/4/2021 to 2/18/2021)
>
>
>
> Hi All,
>
>
>
> I support the adoption.
>
> 1) Yes
>
> 2) Yes
>
> 3) Yes
>
>
>
> Best Regards,
>
> Zhenbin (Robin)
>
>
>
>
>
>
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On
> Behalf Of *Susan Hares
> *Sent:* Thursday, February 4, 2021 11:38 PM
> *To:* idr@ietf.org
> *Subject:* [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt
> (2/4/2021 to 2/18/2021)
>
>
>
> This begins a 2 week WG adoption call for draft-wang-idr-rd-orf-05.txt
> (from 2/4/2021 to 2/18/2021)
>
>
>
> This draft defines a new Outbound Route Filter (ORF) type, called the
>
> Route Distinguisher ORF (RD-ORF).  RD-ORF is applicable when the
>
> routers do not exchange VPN routing information directly (e.g.
>
> routers in single-domain connect via Route Reflector, or routers in
>
> Option B/Option AB/Option C cross-domain scenario).
>
>
>
> Please be aware that this draft has one IPR statement attached.
>
> https://datatracker.ietf.org/ipr/4579/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/4579/__;!!BhdT!3JFUDaX3WxfXuq0-jDevFeHNv4xKPBpOZ-cktrZ8Hg9b1Ipaj0PIHJh3ZFw$>..
>
>
>
> Please consider the following questions in your review and comments:
>
>
>
> 1) Will this new ORF filter reduce routing information at key points?
>
> 2) Should the WG consider this draft given it has an IPR claim or
>
>     Would the IDR WG prefer another approach?
>
> 3) Is this draft ready to be adopted and refined as WG draft?
>
>
>
> Cheerily, Susan Hares
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!yysdkGCNAgoHWvY47NKedcAHI_Yf6MRpOT4zgCSp7HcB9m4Q73F8OU36k5sDVys$>
>
> _______________________________________________
> 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