Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

In-line

Kind Regards

Gyan

On Mon, Aug 24, 2020 at 4:28 PM Fomin, Sergey (Nokia - US/Mountain View) <
sergey.fomin@nokia.com> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Wei Wang,
>
>
>
>
>
> From your description of existing solutions:
>
>
>
>
>
> >   4) Configure the Maximum Prefix for each VRF on edge nodes
>
>
> >
>
>
> >   When a VRF overflows, PE will break down the BGP session with RR
>
>
> >   according to the Maximum Prefix mechanism.  However, there may have
>
>
> >   several VRFs on PE rely on the PE-RR session, this mechanism will
>
>
> >   influence other VRFs.
>
>
> This is not correct. A good implementation of _per-vrf prefix-limit_ does
> not mandate MP-BGP session teardown, it allows to use soft actions instead,
> such as discard routes + log.
>
> Gyan> Sorry we will redo the verbiage and good catch as there is not any
> tear down in the BGP sessions.  Routes above the maximum are clipped and
> not installed into the VRF rib where the overflow occurred and  discard
> routes are logged.
>

>
>
>
> Additionally, if you insist that a local-only discard mechanism is not
> good enough (why?) and you want to prevent route advertisement(s) from an
> RR/remote PE for a specific VRF, it is hard to see real-world benefits of
> the proposed solution
>
> vs, for example, extra logic on top of RTC (i.e. if you implement a
> feature "withdraw an RTC route after FIB/memory utilization reaches 95%").
> Yes, RD-ORF might be a bit more granular in such case, but does it bring
> any benefit? VRF with 50% reachability or
>
> VRF with 0% reachability from a given PE are both examples of unintended
> network state (and the earlier could be worse) that requires intervention.
>
> Gyan>The primary use case is for inter as where either option b or c are
> used outside of administrative domain and a flood of routes are propagated
> between domains.  Within a single domain under one administrative control
> the operators have the control mechanism with PE-CR maximum prefix or per
> VRF maximum prefix which provides control of route thrashing, however their
> maybe corner cases where that is not enough protection and so then within
> domain an RD-ORF can be utilized to mitigate unwanted flooding as well as
> an added protection mechanism.
>
>
>
>
> --
>
>
> Sergey
>
>
>
>
>
>
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *
>
> wangw36@chinatelecom.cn
>
>
> *Sent:* Sunday, August 23, 2020 6:51 PM
>
>
> *To:* idr <idr@ietf.org>
>
>
> *Subject:* Re: [Idr] New Version Notification for
> draft-wang-idr-rd-orf-03.txt
>
>
>
>
>
>
>
>
>
>
>
> Hi IDR experts,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Based on the previous discussion, we update our draft as follows:
>
>
>
>
>
>
>
>
>
>    -
>
>    the description of the limitations of existing solutions is added
>    -
>
>    clarifying that the operation process of RD-ORF on each device is
>    independent
>    -
>
>    modifying the withdraw mechanism of RD-ORF
>
>
>
>
>
>
>
>     Any comments are welcome.
>
>
>
>
>
>
>
>
>
> Best Regards.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
>
>
>
>
>
>
>
>
>
> Wei Wang
>
>
>
>
>
>
> China Telecom
>
>
>
>
>
>
>
>
>
>
>
>
>
> wangw36@chinatelecom.cn
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* internet-drafts <internet-drafts@ietf.org>
>
>
>
>
>
>
> *Date:* 2020-08-24 09:43
>
>
>
>
>
>
> *To:* Haibo
>
> Wang <rainsword.wang@huawei.com>; Gyan S. Mishra
> <gyan.s.mishra@verizon.com>;
>
> Wei Wang <wangw36@chinatelecom.cn>; Aijun Wang <wangaj3@chinatelecom.cn>;
>
> Shunwan Zhuang <zhuangshunwan@huawei.com>; Jie Dong <jie.dong@huawei.com>;
>
>
> Gyan Mishra <gyan.s.mishra@verizon.com>
>
>
>
>
>
>
> *Subject:* New Version Notification for draft-wang-idr-rd-orf-03.txt
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> A new version of I-D, draft-wang-idr-rd-orf-03.txt
>
>
>
>
>
>
> has been successfully submitted by Wei Wang and posted to the
>
>
>
>
>
>
> IETF repository.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Name: draft-wang-idr-rd-orf
>
>
>
>
>
>
> Revision: 03
>
>
>
>
>
>
> Title: Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4
>
>
>
>
>
>
> Document date: 2020-08-24
>
>
>
>
>
>
> Group: Individual Submission
>
>
>
>
>
>
> Pages: 14
>
>
>
>
>
>
> URL:
>
> https://www.ietf.org/internet-drafts/draft-wang-idr-rd-orf-03.txt
>
>
>
>
>
>
> Status:
>
> https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/
>
>
>
>
>
>
> Htmlized:
>
> https://tools.ietf.org/html/draft-wang-idr-rd-orf-03
>
>
>
>
>
>
> Htmlized:
>
> https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf
>
>
>
>
>
>
> Diff:
>
> https://www.ietf.org/rfcdiff?url2=draft-wang-idr-rd-orf-03
>
>
>
>
>
>
>
>
>
>
>
>
>
> Abstract:
>
>
>
>
>
>
>    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 note that it may take a couple of minutes from the time of
> submission
>
>
>
>
>
>
> until the htmlized version and diff are available at tools.ietf.org.
>
>
>
>
>
>
>
>
>
>
>
>
>
> The IETF Secretariat
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> 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