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

[Gyan Mishra <[e-mail]>]

RTC does help as a nice control point inter domain  for L3 VPN with options
AB B C as in this case as opposed to general intra domain case as not every
RT advertisement inter domain is being imported on the PEs where in intra
domain only if their is VRF discontinuity as they don’t all exist on all
PEs that RTC can be helpful as well.  So in the inter domain context  of AB
B C we now having the extra granularity to drop on RD origin offender
between domains using RD-ORF instead of having to filter based on RT at the
ASBR.

Thanks

Gyan

On Wed, Aug 26, 2020 at 4:34 PM Fomin, Sergey (Nokia - US/Mountain View) <
[e-mail]> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks Robert,
>
>
>
>
>
> Indeed I should’ve been more precise on the vrf-limit implementation
> wording as in vrf rib vs mp-bgp rib.
>
>
> Strictly speaking, one may choose to do an implementation in which all
> non-imported routes are discarded from adj-rib-in/loc-rib (i.e. treat the
> limit as logical part of an import-policy), though this doesn’t make much
> sense in 99.9% of
>
> cases.
>
>
>
>
>
> Agree with the rest of the points.
>
>
> --
>
>
> Sergey
>
>
>
>
>
> *From:* Robert Raszuk <[e-mail]>
>
>
> *Sent:* Wednesday, August 26, 2020 12:58 AM
>
>
> *To:* Wei Wang <[e-mail]>
>
>
> *Cc:* Fomin, Sergey (Nokia - US/Mountain View) <[e-mail]>;
> [e-mail]; idr <[e-mail]>; UTTARO, JAMES <[e-mail]
> >
>
>
> *Subject:* Re: [Idr] New Version Notification for
> draft-wang-idr-rd-orf-03.txt
>
>
>
>
>
>
>
> Allow me to clarify a few things here.
>
>
>
>
>
>
>
>
>
>
>
> VRF-LIMIT does not and should not discard routes. It only stops import and
> logs the exceeded message. The route is still in VPNv4 table. Best path
> indeed is needed in the vpnv4 table.
>
>
>
>
>
>
>
>
>
>
>
>
>
> PREFIX-LIMIT does drop the routes and can bring down the session. Best
> path is not executed. This is very cheap operation. Btw - by
>
>
>
>
>
>
> default PE only accepts routes carrying RTs matching at least one local
> import anyway.
>
>
>
>
>
>
>
>
>
>
>
>
>
> - - -
>
>
>
>
>
>
>
>
>
>
>
>
>
> In this entire thread no one explained in technical terms why use of
> prefix limit on the customer <--> service provider boundary is not
> sufficient to prevent from the issues this work seems to be targeting. The
> only explanation given that
>
> this is one way and why not to invent yet another way. That explanation is
> not sufficient.
>
>
>
>
>
>
>
>
>
>
>
>
>
> I see that some may think that maybe there is one weak PE among 100 of
> powerful PEs and such weak PE should not be receiving all routes. Well if
> this is the case this is an operational mistake and not something we should
> address with any
>
> protocol extension. In L2 or L3 VPNs number of routes (IP prefixes or
> MACs) should be bounded and well known allowing to plan the deployments
> well. If an operator is missing that critical operational state that is
> pretty bad.
>
>
>
>
>
>
>
>
>
>
>
>
>
> As far as reachability IMO 0% reachability is much better then random 50%
> for a given VPN customer. When you have no reachability it is very easy to
> troubleshoot. When you have partial reachability it is a nightmare with
> current tools we
>
> have.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thx,
>
>
>
>
>
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thx,
>
>
>
>
>
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Aug 26, 2020 at 4:11 AM Wei Wang <[e-mail]> wrote:
>
>
>
>
>
>
>
>
> Hi Sergey,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Before route discarding, the router must parse the BGP updates, perform
> BGP best path algorithm. These processes will cost CPU cycles and further
> burden the overflowing PE.  Flitering these updates at the sender side can
> ease such process,
>
> this is the same aim as other ORF mechanism.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Best Regards,
>
>
>
>
>
>
>
>
>
>
>
>
>
> Wei Wang
>
>
>
>
>
>
> China Telecom
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------ Original ------------------
>
>
>
>
>
>
>
>
> *From:* "Fomin, Sergey (Nokia - US/Mountain View)" <[e-mail]
> >;
>
>
>
>
>
>
> *Date:* Wed, Aug 26, 2020 04:57 AM
>
>
>
>
>
>
> *To:* "[e-mail]"<[e-mail]>;
>
>
>
>
>
>
> *Cc:* "idr"<[e-mail]>;"UTTARO,
>
> JAMES"<[e-mail]>;
>
>
>
>
>
>
> *Subject:* Re: [Idr] New Version Notification for
> draft-wang-idr-rd-orf-03.txt
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Wei Wang,
>
>
>
>
>
> *>> But the soft actions cannot reduce the burden of PE.*
>
>
>
>
> *>> Because for the overflow PE, a local-only discard mechanism can't make
> it better. If it receive more VPN routes continuously, it must waste more
> resources to log them.*
>
>
>
> Probably we look at this from different perspectives, could you please
> clarify what exact burden and resources are we talking about?
>
>
>
>
>
> In my view, route discard is a cheap operation in terms of CPU cycles, and
> discarded routes use no RIB or FIB resources.
>
>
>
>
>
>
>
> --
>
>
> Sergey
>
>
>
>
>
>
>
>
>
>
>
> *From:*
>
> [e-mail] <[e-mail]>
>
>
>
>
> *Sent:* Monday, August 24, 2020 7:12 PM
>
>
> *To:* UTTARO, JAMES <[e-mail]>; Fomin, Sergey (Nokia - US/Mountain
> View) <[e-mail]>
>
>
> *Cc:* idr <[e-mail]>
>
>
> *Subject:* Re: RE: [Idr] New Version Notification for
> draft-wang-idr-rd-orf-03.txt
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Sergey and Jim,
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks for your review. Please see comments in-line.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Best Regards,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Wei Wang
>
>
>
>
>
>
> China Telecom
>
>
>
>
>
>
>
>
>
>
>
> [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* UTTARO, JAMES <[e-mail]>
>
>
>
>
>
>
>
>
> *Date:* 2020-08-25 05:43
>
>
>
>
>
>
>
>
> *To:* Fomin, Sergey (Nokia - US/Mountain View) <[e-mail]>;
>
> [e-mail]
>
>
>
>
>
>
>
>
> *CC:* idr <[e-mail]>
>
>
>
>
>
>
>
>
> *Subject:* RE: [Idr] New Version Notification for
> draft-wang-idr-rd-orf-03.txt
>
>
>
>
>
>
>
>
>
>
>
>
> *Comments In-Line.*
>
>
>
>
>
> *Thanks,*
>
>
> *              Jim Uttaro*
>
>
>
>
>
>
>
>
>
> *From:* Idr <[e-mail]>
>
> *On Behalf Of *Fomin, Sergey (Nokia - US/Mountain View)
>
>
> *Sent:* Monday, August 24, 2020 4:28 PM
>
>
> *To:* [e-mail]
>
>
> *Cc:* idr <[e-mail]>
>
>
> *Subject:* Re: [Idr] New Version Notification for
> draft-wang-idr-rd-orf-03.txt
>
>
>
>
>
>
>
>
>
> 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.
>
>
>
>
> *[Jim U>] Yup.. That is the way my implementations work.. The goal is to
> ensure maximum correctness of a given VPN. Tearing down the PE-RR session
> is killing a fly with a sledge hammer..*
>
>
> *[Wei Wang] But the soft actions cannot reduce the burden of PE.*
>
>
>
>
>
> Additionally, if you insist that a local-only discard mechanism is not
> good enough (why?)
>
>
>
>
> *[Wei Wang] Because for the overflow PE, a local-only discard mechanism
> can't make it better. If it receive more VPN routes continuously, it must
> waste more resources to log them.*
>
>
>  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%").
>
>
> *[Wei Wang] Yes, VRF with 0% reachability may be achieved in this way.*
>
>
>  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.
>
>
> *[Wei Wang] In my opinion, VRF with 50% reachability may be able to keep
> part of user traffic normal. It is better than VRF with 0% reachability.*
>
>
>
>
>
> --
>
>
> Sergey
>
>
>
>
>
>
>
>
>
> *From:* Idr <[e-mail]>
>
> *On Behalf Of *[e-mail]
>
>
> *Sent:* Sunday, August 23, 2020 6:51 PM
>
>
> *To:* idr <[e-mail]>
>
>
> *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
>
>
>
>
>
>
>
>
>
>
>
>
>
> [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* internet-drafts <[e-mail]>
>
>
>
>
>
>
>
>
> *Date:* 2020-08-24 09:43
>
>
>
>
>
>
>
>
> *To:* Haibo Wang <[e-mail]>;
>
> Gyan S. Mishra <[e-mail]>;
>
> Wei Wang <[e-mail]>;
>
> Aijun Wang <[e-mail]>;
>
> Shunwan Zhuang <[e-mail]>;
>
> Jie Dong <[e-mail]>;
>
> Gyan Mishra <[e-mail]>
>
>
>
>
>
>
>
>
> *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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dwang-2Didr-2Drd-2Dorf-2D03.txt&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=14kL4f6cO3I39QTIY9-i3boaLA2giY4KiD3j2Tu9fi0&e=>
>
>
>
>
>
>
> Status:
>
> https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwang-2Didr-2Drd-2Dorf_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=Aw-Mc7bSxvLnYtxEpzTjMz5qVGpXvLZRkDb0Ze8kZ0I&e=>
>
>
>
>
>
>
> Htmlized:
>
> https://tools.ietf.org/html/draft-wang-idr-rd-orf-03
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D03&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=PIKT-TH9C9zny7t-hQj9xqSwHgV_XG4VXGx5sMbWTJg&e=>
>
>
>
>
>
>
> Htmlized:
>
> https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dwang-2Didr-2Drd-2Dorf&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=Tre2skoFxacQ9M124fvYpANTrlrA5iYvyGv_RdEOntc&e=>
>
>
>
>
>
>
> Diff:
>
> https://www.ietf.org/rfcdiff?url2=draft-wang-idr-rd-orf-03
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dwang-2Didr-2Drd-2Dorf-2D03&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=CcQDMR1B4HvydxNGlDcsW01YUNWiuGyrtr_o1w2wWnE&e=>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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
>
>
> [e-mail]
>
>
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Idr mailing list
>
> [e-mail]
>
> 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