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

From: "Wei Wang" <[email-masked]>
Date: Wed, 26 Aug 2020 10:11:35 +0800

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.&nbsp; 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

------------------&nbsp;Original&nbsp;------------------
From:                                                                                                                        "Fomin, Sergey (Nokia - US/Mountain View)"                                                                                    <[email-masked]&gt;;
Date:&nbsp;Wed, Aug 26, 2020 04:57 AM
To:&nbsp;"[email-masked]"<[email-masked]&gt;;
Cc:&nbsp;"idr"<[email-masked]&gt;;"UTTARO, JAMES"<[email-masked]&gt;;
Subject:&nbsp;Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi Wei Wang,
 
&nbsp;
 
&gt;&gt; But the soft actions cannot reduce the burden of PE.&nbsp;
 
&gt;&gt; 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?
 
&nbsp;
 
In my view, route discard is a cheap operation in terms of CPU cycles, and discarded routes use no RIB or FIB resources.
 
&nbsp;
  
--
 
Sergey

&nbsp;
   
From: [email-masked] <[email-masked]&gt; 
 Sent: Monday, August 24, 2020 7:12 PM
 To: UTTARO, JAMES <[email-masked]&gt;; Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]&gt;
 Cc: idr <[email-masked]&gt;
 Subject: Re: RE: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

&nbsp;
   
Hi Sergey and Jim,

&nbsp;

Thanks for your review. Please see comments in-line.

&nbsp;

Best Regards,

&nbsp;

Wei Wang

China Telecom

&nbsp;

[email-masked]&nbsp; 
 &nbsp;

From:&nbsp;UTTARO,  JAMES

Date:&nbsp;2020-08-25 05:43

To:&nbsp;Fomin,  Sergey (Nokia - US/Mountain View); [email-masked]

CC:&nbsp;idr

Subject:&nbsp;RE: [Idr] New Version Notification for  draft-wang-idr-rd-orf-03.txt

   
Comments In-Line.
 
&nbsp;
 
Thanks,
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; Jim Uttaro
 
&nbsp;
   
From: Idr <[email-masked]&gt; On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
 Sent: Monday, August 24, 2020 4:28 PM
 To: [email-masked]
 Cc: idr <[email-masked]&gt;
 Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

&nbsp;
 
Hi Wei Wang,
 
&nbsp;
 
From your description of existing solutions:
 
&nbsp;
 
&gt; &nbsp; 4) Configure the Maximum Prefix for each VRF on edge nodes
 
&gt; 
 
&gt; &nbsp; When a VRF overflows, PE will break down the BGP session with RR
 
&gt; &nbsp; according to the Maximum Prefix mechanism.&nbsp; However, there may have
 
&gt; &nbsp; several VRFs on PE rely on the PE-RR session, this mechanism will
 
&gt; &nbsp; 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&gt;] 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.
 
&nbsp;
 
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.
 
&nbsp;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.
 
&nbsp;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.
 
&nbsp;
 
--
 
Sergey
 
&nbsp;
   
From: Idr <[email-masked]&gt; On Behalf Of [email-masked]
 Sent: Sunday, August 23, 2020 6:51 PM
 To: idr <[email-masked]&gt;
 Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

&nbsp;
  
Hi IDR experts,

&nbsp;

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

&nbsp; &nbsp; Any comments are welcome.

&nbsp;
  
Best Regards.

&nbsp;

&nbsp;

 
    
Wei Wang

China Telecom

&nbsp;

[email-masked]

   
&nbsp;

From:&nbsp;internet-drafts

Date:&nbsp;2020-08-24 09:43

To:&nbsp;Haibo  Wang; Gyan S. Mishra; Wei Wang; Aijun Wang; Shunwan Zhuang; Jie Dong; Gyan Mishra

Subject:&nbsp;New Version Notification for draft-wang-idr-rd-orf-03.txt

   
&nbsp;

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.

&nbsp;

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:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  https://www.ietf.org/internet-drafts/draft-wang-idr-rd-orf-03.txt

Status:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/

Htmlized:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  https://tools.ietf.org/html/draft-wang-idr-rd-orf-03

Htmlized:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf

Diff:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  https://www.ietf.org/rfcdiff?url2=draft-wang-idr-rd-orf-03

&nbsp;

Abstract:

&nbsp;&nbsp; This draft defines a new Outbound Route Filter (ORF) type, called the

&nbsp;&nbsp; Route Distinguisher ORF (RD-ORF).&nbsp; RD-ORF is applicable when the

&nbsp;&nbsp; routers do not exchange VPN routing information directly (e.g.

&nbsp;&nbsp; routers in single-domain connect via Route Reflector, or routers in

&nbsp;&nbsp; Option B/Option AB/Option C cross-domain scenario).

&nbsp;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  

&nbsp;

&nbsp;

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.

&nbsp;

The IETF Secretariat

&nbsp;

&nbsp;

&nbsp;

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Aug 2020 09:58:09 +0200

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 <[email-masked]> 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)" <[email-masked]
> >;
> *Date:* Wed, Aug 26, 2020 04:57 AM
> *To:* "[email-masked]"<[email-masked]>;
> *Cc:* "idr"<[email-masked]>;"UTTARO, JAMES"<[email-masked]>;
> *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:* [email-masked] <[email-masked]>
> *Sent:* Monday, August 24, 2020 7:12 PM
> *To:* UTTARO, JAMES <[email-masked]>; Fomin, Sergey (Nokia - US/Mountain
> View) <[email-masked]>
> *Cc:* idr <[email-masked]>
> *Subject:* Re: RE: [Idr] New Version Notification for
> draft-wang-idr-rd-orf-03.txt
>
>
>
> Hi Sergey and Jim,
>
>
>
> ------------------------------
>
> Wei Wang
>
> China Telecom
>
>
>
> [email-masked]
>
>
> *From:* UTTARO, JAMES <[email-masked]>
>
> *Date:* 2020-08-25 05:43
>
> *To:* Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]>;
> [email-masked]
>
> *CC:* idr <[email-masked]>
>
> *Subject:* RE: [Idr] New Version Notification for
> draft-wang-idr-rd-orf-03.txt
>
> *Comments In-Line.*
>
>
>
> *Thanks,*
>
> *              Jim Uttaro*
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Fomin, Sergey (Nokia -
> US/Mountain View)
> *Sent:* Monday, August 24, 2020 4:28 PM
> *To:* [email-masked]
> *Cc:* idr <[email-masked]>
> *Subject:* Re: [Idr] New Version Notification for
> draft-wang-idr-rd-orf-03.txt
>
>
>
> Hi Wei Wang,
>
>
>
> >   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.*
>
>
>
> *[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 <[email-masked]> *On Behalf Of [email-masked]
> *Sent:* Sunday, August 23, 2020 6:51 PM
> *To:* idr <[email-masked]>
> *Subject:* Re: [Idr] New Version Notification for
> draft-wang-idr-rd-orf-03.txt
>
>
>
> Hi IDR experts,
>
>
>
>    - 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
>
>
>
> [email-masked]
>
>
>
> *From:* internet-drafts <[email-masked]>
>
> *Date:* 2020-08-24 09:43
>
> *To:* Haibo Wang <[email-masked]>; Gyan S. Mishra
> <[email-masked]>; Wei Wang <[email-masked]>; Aijun
> Wang <[email-masked]>; Shunwan Zhuang <[email-masked]>;
> Jie Dong <[email-masked]>; Gyan Mishra <[email-masked]>
>
> *Subject:* New Version Notification for draft-wang-idr-rd-orf-03.txt
>
>
>
> 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).
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 26 Aug 2020 11:58:01 -0400

Robert

Good points and agreed.  That needs to be clarified.

> indeed is needed in the vpnv4 table.

  Gyan> Agreed.  Will fix the verbiage. The VPN table RR to PE VPN rib has
all routes from each unique RD originator that was reflected by the RR.
The per VRF-LIMIT stops the import of routes into each customer VRF.  By
default all PEs have “RT filtering” enabled so if they don’t have at least
one explicit import the RT is dropped.

>
> PREFIX-LIMIT does drop the routes and can bring down the session. Best
> path is not executed. This is very cheap operation. Btw - by

   Gyan> Agreed.  Bring down session unless you have warning flag with %
threshold set. Understood by default all PEs have “RT filtering” enabled so
if they don’t have at least one explicit import the RT is dropped.

>
> - - -
>
> 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.
>

    Gyan> The primary use case is for inter as opt a or b flood of routes
and there it is very difficult to control in either scenario as it is going
between administrative domains.  One domain may have per VRF maximum prefix
and per maximum prefix set on each PE-CE link while the other domain may
not.  The option b you do have some control but at the PE ASBR as you have
to do a retain-route-target-all as RT filtering is enabled on PEs by
default and then you are either doing RT translation or filtering by RT but
don’t have any other granularity.  As the RD has to be unique for RR to
reflect all paths the RD-ORF cab filter on origin RD from the other AS and
that could be beneficial versus sledge hammer filtering on the RT level
blocking all prefixes for the VRF.  For option c as the RR does not have RT
filtering enabled by default and floods all routes the RD-ORF mechanisms
can provide control of flood of routes as well as with option c where the
route origin is outside or the administrative boundary.

> powerful PEs and such weak PE should not be receiving all routes.. Well if

    Gyan> Agreed

> troubleshoot. When you have partial reachability it is a nightmare with

   Gyan> Agreed no routes is better then few less routes from a
troubleshooting perspective.

>> *From:* "Fomin, Sergey (Nokia - US/Mountain View)" <
>> [email-masked]>;
>> *>> 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.*
>>
>
>>
>> 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:* UTTARO,
>> JAMES <[email-masked]>
>> *To:* Fomin,
>> Sergey (Nokia - US/Mountain View) <[email-masked]>;
>>
>> [email-masked]
>>
>>
>>
>>
>>
>>
>> *CC:* idr <[email-masked]>
>>
>>
>>
>>
>>
>>
>> *From:* Idr <[email-masked]>
>>
>> *On Behalf Of *Fomin, Sergey (Nokia - US/Mountain View)
>>
>>
>>  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
>> given PE are both examples of unintended network state (and the
>>
>> earlier could be worse) that requires intervention.
>>
>>
>> *From:* Idr <[email-masked]>
>>
>> *On Behalf Of [email-masked]
>>
>>
>> *To:* Haibo
>> Wang <[email-masked]>;
>>
>> Gyan S. Mishra <[email-masked]>;
>>
>> Wei Wang <[email-masked]>;
>>
>> Aijun Wang <[email-masked]>;
>>
>> Shunwan Zhuang <[email-masked]>;
>>
>> Jie Dong <[email-masked]>;
>>
>> Gyan Mishra <[email-masked]>
>>
>>
>>
>>
>>
>>
>> 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

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Aug 2020 18:08:22 +0200

> Gyan> The primary use case is for inter as opt a or b flood of routes and
there it is very difficult to control
> in either scenario as it is going between administrative domains.

For inter-as option A you should use prefix limit between VRFs.

For inter-as option B & C it is very seldom to see opening up anyone's
network across different admin domains. Lot's of things can break. The only
deployments I have seen for option B & C were across multiple domains under
the *same* administration.

However if you are concerned about B & C I would rather ask your vendor to
provide perfix limit on a per RD basis for VPNv4/v6 or EVPN sessions - no
best path run needed. Very simple implementation extension and you are
protected without any bgp protocol extensions.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Aug 2020 18:19:12 +0200

Just to add one point I forgot to mention - You can also enable and use
Inter-as option "*AB"*

Protection as good as in option A with inherent native scalability of
option B. Has been supported and deployed for years ...

Thx,
R.

REF:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_ias_and_csc/configuration/xe-16/mp-ias-and-csc-xe-16-book/mpls-vpn-inter-as-option-ab.html

On Wed, Aug 26, 2020 at 6:08 PM Robert Raszuk <[email-masked]> wrote:

> and there it is very difficult to control

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 26 Aug 2020 12:23:16 -0400

> For inter-as option A you should use prefix limit between VRFs.

   Gyan>Understood sorry I meant B and C.

> the *same* administration.

   Gyan> Agreed I think more so for M&A  or where there is a trust
relationship between providers.  In general its options A or AB between
providers.

*Gyan Mishra*

---

From: "Fomin, Sergey (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 26 Aug 2020 20:33:39 +0000

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 <[email-masked]>
Sent: Wednesday, August 26, 2020 12:58 AM
To: Wei Wang <[email-masked]>
Cc: Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]>; [email-masked]; idr <[email-masked]>; UTTARO, JAMES <[email-masked]>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

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 <[email-masked]<mailto:[email-masked]>> 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)" <[email-masked]<mailto:[email-masked]>>;
Date: Wed, Aug 26, 2020 04:57 AM
To: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>;
Cc: "idr"<[email-masked]<mailto:[email-masked]>>;"UTTARO, JAMES"<[email-masked]<mailto:[email-masked]>>;
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.

--
Sergey

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 24, 2020 7:12 PM
To: UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>
Cc: idr <[email-masked]<mailto:[email-masked]>>
Subject: Re: RE: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi Sergey and Jim,

Best Regards,

________________________________
Wei Wang
China Telecom

[email-masked]<mailto:[email-masked]>

From: UTTARO, JAMES<mailto:[email-masked]>
Date: 2020-08-25 05:43
To: Fomin, Sergey (Nokia - US/Mountain View)<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: idr<mailto:[email-masked]>
Subject: RE: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt
Comments In-Line.

Thanks,
              Jim Uttaro

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Monday, August 24, 2020 4:28 PM
To: [email-masked]<mailto:[email-masked]>
Cc: idr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi Wei Wang,

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 <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Sunday, August 23, 2020 6:51 PM
To: idr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi IDR experts,

  *   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

[email-masked]<mailto:[email-masked]>

From: internet-drafts<mailto:[email-masked]>
Date: 2020-08-24 09:43
To: Haibo Wang<mailto:[email-masked]>; Gyan S. Mishra<mailto:[email-masked]>; Wei Wang<mailto:[email-masked]>; Aijun Wang<mailto:[email-masked]>; Shunwan Zhuang<mailto:[email-masked]>; Jie Dong<mailto:[email-masked]>; Gyan Mishra<mailto:[email-masked]>
Subject: New Version Notification for draft-wang-idr-rd-orf-03.txt

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:

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<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 26 Aug 2020 18:42:26 -0400

Agreed that AB is a nice hybrid of A VRF data plane isolation security with
the scalability of single VPN session which was the drawback for optA.

We will add some verbiage around AB as that is as you suggested much more
common as it resolved the pitfalls of both A and B.

Thanks

Gyan

On Wed, Aug 26, 2020 at 12:19 PM Robert Raszuk <[email-masked]> wrote:

>> However if you are concerned about B & C I would rather ask your vendor
>> to provide perfix limit on a per RD basis for VPNv4/v6 or EVPN sessions -
>> no best path run needed. Very simple implementation extension and you are

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 26 Aug 2020 19:00:33 -0400

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) <
[email-masked]> wrote:

> 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.
>
>
>
>
>
> *From:* Robert Raszuk <[email-masked]>
>
>
> *Sent:* Wednesday, August 26, 2020 12:58 AM
>
>
> *To:* Wei Wang <[email-masked]>
>
>
> *Cc:* Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]>;
> [email-masked]; idr <[email-masked]>; UTTARO, JAMES <[email-masked]
> >
>
>
> only explanation given that
>
> this is one way and why not to invent yet another way. That explanation is
> not sufficient.
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
> current tools we
> have.
> ease such process,
> this is the same aim as other ORF mechanism.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Best Regards,
>
>
>
>
>
>
>
>
>
>
>
>
>
> Wei Wang
>
>
>
>
>
>
> China Telecom
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Cc:* "idr"<[email-masked]>;"UTTARO,
>
> JAMES"<[email-masked]>;
>
>
>
>
>
>
> *From:*
> [email-masked] <[email-masked]>
>
>
>
>
> such
> as discard routes + log.
> 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%").
>
>
> given
> PE are both examples of unintended network state (and the earlier could be
> worse) that requires intervention.
>
>
>    -
>    -
>    -
> *To:* Haibo Wang <[email-masked]>;
>
> until the htmlized version and diff are available at
>
> tools.ietf.org.
>
>
>
>
>
>
>
>
>
>
>
>
>
> The IETF Secretariat
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

*Gyan Mishra*

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 27 Aug 2020 09:17:44 +0800

Hi, Sergey and Robert:

Local discard based on vrf-limit or other mechanism doesn’t release the overwhelming PE from parsing the overloaded BGP updates and BGP best path algorithm,  

Implementing the RD-based filter policy internal is possible but why not advertise it further to the upstream neighbor, which conforms to the aim and procedures of established ORF mechanism?

Don’t’ you think that based on RD-ORF control mechanism,  inter-AS option B, C and AB can all be safely deployed within inter-domain scenarios, not only for the M&A or between ASes that under the same admin, especially for the non-mpls environment?

More detail responses are inline.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Thursday, August 27, 2020 4:34 AM
To: Robert Raszuk <[email-masked]>
Cc: idr <[email-masked]>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Thanks Robert,

--

Sergey

From: Robert Raszuk <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, August 26, 2020 12:58 AM
To: Wei Wang <[email-masked] <mailto:[email-masked]> >
Cc: Fomin, Sergey (Nokia - US/Mountain View) <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; idr <[email-masked] <mailto:[email-masked]> >; UTTARO, JAMES <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

- - - 

[WAJ] RD-ORF mechanism is mainly for option B/C or AB, can also be used within one domain that enhance the internal anti-attack capabilities.

[WAJ] RD-ORF from the weak PE will not influence other PEs, as this messages is sent independently via PE，RR or ASBR, as stated in the updated version of this draft. 

[WAJ] The reason to constraint the VRF routes based on RD & Source Router info, not the entire routes within one VRF, is to limit the influences only to the overwhelming PE.  Or else, the communication among the PEs within one VRF will all be stopped. 

Isn’t it better to stop only the communication between the overwhelmed PE and overwhelming PE in such situation?

For troubleshoot, don’t’ you agree RD-ORF give the clues to find the reason?  We don’t’ discard the routes in silence.    

Thx,

R.

Thx,

R.

 

 

On Wed, Aug 26, 2020 at 4:11 AM Wei Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi Sergey,

Best Regards,

Wei Wang

China Telecom

------------------ Original ------------------

From: "Fomin, Sergey (Nokia - US/Mountain View)" < <mailto:[email-masked]> [email-masked]>;

To: " <mailto:[email-masked]> [email-masked]"< <mailto:[email-masked]> [email-masked]>;

Cc: "idr"< <mailto:[email-masked]> [email-masked]>;"UTTARO, JAMES"< <mailto:[email-masked]> [email-masked]>;

Hi Wei Wang,

--

Sergey

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, August 24, 2020 7:12 PM
To: UTTARO, JAMES <[email-masked] <mailto:[email-masked]> >; Fomin, Sergey (Nokia - US/Mountain View) <[email-masked] <mailto:[email-masked]> >
Cc: idr <[email-masked] <mailto:[email-masked]> >
Subject: Re: RE: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi Sergey and Jim,

Best Regards,

  _____  

Wei Wang

China Telecom

 <mailto:[email-masked]> [email-masked]  

From:  <mailto:[email-masked]> UTTARO, JAMES

Date: 2020-08-25 05:43

To:  <mailto:[email-masked]> Fomin, Sergey (Nokia - US/Mountain View);  <mailto:[email-masked]> [email-masked]

CC:  <mailto:[email-masked]> idr

Comments In-Line.

Thanks,

              Jim Uttaro

From: Idr <[email-masked] <mailto:[email-masked]> > On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Monday, August 24, 2020 4:28 PM
To: [email-masked] <mailto:[email-masked]> 
Cc: idr <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi Wei Wang,

--

Sergey

From: Idr <[email-masked] <mailto:[email-masked]> > On Behalf Of [email-masked] <mailto:[email-masked]> 
Sent: Sunday, August 23, 2020 6:51 PM
To: idr <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi IDR experts,

·       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

Best Regards.

  _____  

Wei Wang

China Telecom

 <mailto:[email-masked]> [email-masked]

From:  <mailto:[email-masked]> internet-drafts

Date: 2020-08-24 09:43

To:  <mailto:[email-masked]> Haibo Wang;  <mailto:[email-masked]> Gyan S. Mishra;  <mailto:[email-masked]> Wei Wang;  <mailto:[email-masked]> Aijun Wang;  <mailto:[email-masked]> Shunwan Zhuang;  <mailto:[email-masked]> Jie Dong;  <mailto:[email-masked]> Gyan Mishra

IETF repository.

Revision: 03

Pages: 14

URL:            <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=> https://www.ietf.org/internet-drafts/draft-wang-idr-rd-orf-03.txt

Status:         <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=> https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/

Htmlized:       <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=> https://tools.ietf.org/html/draft-wang-idr-rd-orf-03

Htmlized:       <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=> https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf

Diff:           <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=> https://www.ietf.org/rfcdiff?url2=draft-wang-idr-rd-orf-03

Abstract:

                                                                                 

until the htmlized version and diff are available at  <http://tools.ietf.org> tools.ietf.org.

The IETF Secretariat

_______________________________________________
Idr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Aug 2020 10:46:35 +0200

> doesn’t release the overwhelming PE from parsing the overloaded BGP
updates

No.

By day one design L3VPNs or L2VPNs are overloading all PEs to parse and
drop all BGP updates which do not carry routes containing at least one
intersecting RT. Often amount of such drops are 100s of thousands or
millions at full BGP refresh. If you want to question that I think you
either stop using L3VPN service or use RTC by default. Please observe that
it was never the issue with any BGP implementations I am familiar with,.
Drops are cheap operation.

If you want to locally drop based on the RD is it equally cheap (or even
cheaper operation) then dropping based on RT as RD is part of the NLRI so
you do not even need to parse entire UPDATE msg. Your vendor can implement
it for you. There is no need for any bgp best path calculation in such
situation.

Thx,
R.

On Thu, Aug 27, 2020 at 3:17 AM Aijun Wang <[email-masked]>
wrote:

> Hi, Sergey and Robert:
>
>
>
> Local discard based on vrf-limit or other mechanism doesn’t release the
> overwhelming PE from parsing the overloaded BGP updates and BGP best path
> algorithm,
>
> Implementing the RD-based filter policy internal is possible but why not
> advertise it further to the upstream neighbor, which conforms to the aim
> and procedures of established ORF mechanism?
>
>
>
> Don’t’ you think that based on RD-ORF control mechanism,  inter-AS option
> B, C and AB can all be safely deployed within inter-domain scenarios, not
> only for the M&A or between ASes that under the same admin, especially for
> the non-mpls environment?
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Fomin,
> Sergey (Nokia - US/Mountain View)
> *Sent:* Thursday, August 27, 2020 4:34 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* idr <[email-masked]>
> sense in 99.9% of cases.
> *[WAJ] RD-ORF mechanism is mainly for option B/C or AB, can also be used
> within one domain that enhance the internal anti-attack capabilities.*
>
>
>
> *[WAJ] RD-ORF from the weak PE will not influence other PEs, as this
> messages is sent independently via PE**，RR or ASBR, as stated in the
> updated version of this draft. *
>
>
>
> *[WAJ] The reason to constraint the VRF routes based on RD & Source Router
> info, not the entire routes within one VRF, is to limit the influences only
> to the overwhelming PE.  Or else, the communication among the PEs within
> one VRF will all be stopped. *
>
> *Isn’t it better to stop only the communication between the overwhelmed PE
> and overwhelming PE in such situation?*
>
> *For troubleshoot, don’t’ you agree RD-ORF give the clues to find the
> reason?  We don’t’ discard the routes in silence.    *
>
>
>
> Thx,
>
> R.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 28 Aug 2020 08:52:29 +0800

Hi, Robert:

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Thursday, August 27, 2020 4:47 PM
To: Aijun Wang <[email-masked]>
Cc: Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]>; idr <[email-masked]>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

> doesn’t release the overwhelming PE from parsing the overloaded BGP updates  

No. 

By day one design L3VPNs or L2VPNs are overloading all PEs to parse and drop all BGP updates which do not carry routes containing at least one intersecting RT. 

[WAJ]  But until now, various filter policies for the unnecessary BGP updates has been added, do you agree?

Often amount of such drops are 100s of thousands or millions at full BGP refresh. If you want to question that I think you either stop using L3VPN service or use RTC by default. Please observe that it was never the issue with any BGP implementations I am familiar with,. Drops are cheap operation. 

If you want to locally drop based on the RD is it equally cheap (or even cheaper operation) then dropping based on RT as RD is part of the NLRI so you do not even need to parse entire UPDATE msg. Your vendor can implement it for you. There is no need for any bgp best path calculation in such situation.

[WAJ] Yes, RD-ORF can also be used within the device, but push the policy to its upstream peer or final to the overwhelming source is better.

Thx,

R.

 

 

 

On Thu, Aug 27, 2020 at 3:17 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Sergey and Robert:

 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Thursday, August 27, 2020 4:34 AM
To: Robert Raszuk <[email-masked] <mailto:[email-masked]> >
Cc: idr <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Thanks Robert,

--

Sergey

- - - 

Thx,

R.

Thx,

R.

 

 

Hi Sergey,

Best Regards,

Wei Wang

China Telecom

------------------ Original ------------------

Hi Wei Wang,

--

Sergey

Hi Sergey and Jim,

Best Regards,

  _____  

Wei Wang

China Telecom

Date: 2020-08-25 05:43

Comments In-Line.

Thanks,

              Jim Uttaro

Hi Wei Wang,

--

Sergey

Hi IDR experts,

Best Regards.

  _____  

Wei Wang

China Telecom

Date: 2020-08-24 09:43

IETF repository.

Revision: 03

Pages: 14

Abstract:

                                                                                 

The IETF Secretariat

---

From: "Fomin, Sergey (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 28 Aug 2020 03:51:43 +0000

Hi Aijun Wang,

> [WAJ] Yes, RD-ORF can also be used within the device, but push the policy to its upstream peer or final to the overwhelming source is better.
I’m still struggling to understand how.

Even if we disregard all other protection mechanisms, etc, and even if we assume that indeed this highly specific scenario happens in your network, we get a situation where, based on your comments [use cases in the draft are slightly different, though]:

  1.  that poor PE device struggles to parse newly arriving updates (insufficient CPU? Memory? FIB?)
  2.  at the same time, instead of cheap local actions:
     *   it should parse all these updates
     *   do some math trying to figure out what set of routes should be discarded

                                                    i.     which could end up being a completely different set of existing routes, since the PE is still parsing arriving updates, and we don’t know how routes are distributed across PE/RDs

     *   generate & signal RD-ORF entry to a peer
     *   wait for withdrawal of those NLRIs (more processing!)..
What we are trying to save here?
--
Sergey

From: Aijun Wang <[email-masked]>
Sent: Thursday, August 27, 2020 5:52 PM
To: 'Robert Raszuk' <[email-masked]>
Cc: Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]>; 'idr' <[email-masked]>
Subject: RE: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi, Robert:

No.

Thx,
R.

On Thu, Aug 27, 2020 at 3:17 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Sergey and Robert:

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Thursday, August 27, 2020 4:34 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Thanks Robert,

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 26, 2020 12:58 AM
To: Wei Wang <[email-masked]<mailto:[email-masked]>>
Cc: Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; idr <[email-masked]<mailto:[email-masked]>>; UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

- - -

Thx,
R.

Thx,
R.

Best Regards,

Wei Wang
China Telecom

------------------ Original ------------------
From: "Fomin, Sergey (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>;
Date: Wed, Aug 26, 2020 04:57 AM
To: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>;
Cc: "idr"<[email-masked]<mailto:[email-masked]>>;"UTTARO, JAMES"<[email-masked]<mailto:[email-masked]>>;
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

Hi Wei Wang,

--
Sergey

Hi Sergey and Jim,

Best Regards,

Thanks,
              Jim Uttaro

Hi Wei Wang,

--
Sergey

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.

Abstract:

The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Aug 2020 09:18:50 +0200

> intersecting RT.
> *[WAJ]  But until now, various filter policies for the unnecessary BGP
> updates has been added, do you agree?*
>

There is a difference between "unnecessary" and those which are caused by
wrong service deployment.

*[WAJ] Yes, RD-ORF can also be used within the device, but push the policy
> to its upstream peer or final to the overwhelming source is better.*
>

This is one of the biggest issue I have with this draft. ORF is not
transitive and you are making it transitive (even if you pretend it is
not).

I am not against automated filtering (where it make sense), but if so pls
do it correctly. Define a new SAFI just like we did with RTC, call it RDC
(RD Constrained) and use it at your own risk to break VPNs in your network.

While there custom update generation especially based on more then one
constraint has a high cost. You need to generate update per each such peer
individually walking full vpnv4 table. Dropping is cheap. Replication is
cheap. Keep this in mind pls so your vendor's implementation engineers have
easy life :).

Cheers,
R.

---

From: Aijun Wang <[email-masked]>
Date: Fri, 28 Aug 2020 19:13:45 +0800

Hi，Robert:

Aijun Wang
China Telecom

> On Aug 28, 2020, at 15:19, Robert Raszuk <[email-masked]> wrote:
> 
> 
> There is a difference between "unnecessary" and those which are caused by wrong service deployment. 

[WAJ] Isn’t it better to release you from such risk?

> This is one of the biggest issue I have with this draft. ORF is not transitive and you are making it transitive (even if you pretend it is not). 

[WAJ]: As mentioned earlier, we have updated the draft to state clearly the RD-ORF is non-transitive. Such message will only be received by the overwhelming source when all the nodes along path decide to do such actions. These devices make their decision independently.

> 
> I am not against automated filtering (where it make sense), but if so pls do it correctly. Define a new SAFI just like we did with RTC, call it RDC (RD Constrained) and use it at your own risk to break VPNs in your network. 

[WAJ] Please consider also the inter-as scenarios together.
> 
> While there custom update generation especially based on more then one constraint has a high cost. You need to generate update per each such peer individually walking full vpnv4 table. Dropping is cheap. Replication is cheap. Keep this in mind pls so your vendor's implementation engineers have easy life :). 

[WAJ] There are works needs to be done before dropping the VPN routes. Isn’t such back pressure better than the devices do useless work?

---

From: Aijun Wang <[email-masked]>
Date: Fri, 28 Aug 2020 19:31:38 +0800

Hi, Sergey:
The main purpose of this draft is to prevent the overwhelmed VRF in one PE influence the communications of other VRFs in the same PE.
The PE should do the analysis work in advance continuously. Once one of its VRF is overflow, it should find the source of the overwhelming VPN routes immediately, build and send upstream the RD-ORF message. 
The following BGP updates that match this RD-ORF filter will not be received by the PE then.
This PE can still receive the BGP updates for other VPNs or the same VPN but from different RD/Source Router.

Aijun Wang
China Telecom

> On Aug 28, 2020, at 11:51, Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]> wrote:
> 
> 
> Hi Aijun Wang,
>  
> that poor PE device struggles to parse newly arriving updates (insufficient CPU? Memory? FIB?)

> at the same time, instead of cheap local actions:
> it should parse all these updates
> do some math trying to figure out what set of routes should be discarded
> generate & signal RD-ORF entry to a peer
> wait for withdrawal of those NLRIs (more processing!)..
> On Thu, Aug 27, 2020 at 3:17 AM Aijun Wang <[email-masked]> wrote:
> Hi, Sergey and Robert:
>  
> From: "Fomin, Sergey (Nokia - US/Mountain View)" <[email-masked]>;
> To: "[email-masked]"<[email-masked]>;
> Cc: "idr"<[email-masked]>;"UTTARO, JAMES"<[email-masked]>;
> From: [email-masked] <[email-masked]> 
> To: UTTARO, JAMES <[email-masked]>; Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]>
> Cc: idr <[email-masked]>
> From: UTTARO, JAMES
> To: Fomin, Sergey (Nokia - US/Mountain View); [email-masked]
> CC: idr
> From: Idr <[email-masked]> On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
> From: Idr <[email-masked]> On Behalf Of [email-masked]
> To: idr <[email-masked]>
> From: internet-drafts
> To: Haibo Wang; Gyan S. Mishra; Wei Wang; Aijun Wang; Shunwan Zhuang; Jie Dong; Gyan Mishra
> URL:           https://www.ietf.org/internet-drafts/draft-wang-idr-rd-orf-03.txt

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Aug 2020 14:21:24 +0200

> [WAJ] Please consider also the inter-as scenarios together.

Last time I checked BGP works pretty well in inter-as scenarios.

* * *

All you are asking in this draft can be done today with RTC and both
inter-as and intra-as.

All you need is to add one RT per VRF and you are done.

I really fail to see any reason to define a new protocol extension for a
functionality which is already readily available with exactly the same
functionality. In fact the new RT value can be even identical to RD
numerical value if you already use RD per VRF.

This will do everything you need to do in terms of fine protection plus it
will also not require any single line of implementation.

I highly recommend we drop this thread and move on.

Thx a lot,
R.

---

From: Aijun Wang <[email-masked]>
Date: Fri, 28 Aug 2020 20:36:16 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Aug 28, 2020, at 20:21, Robert Raszuk <[email-masked]> wrote:
> 
> 

[WAJ] Inter-AS B/C or AB. Not Option A

> * * * 
> 
> All you are asking in this draft can be done today with RTC and both inter-as and intra-as. 
> 

[WAJ] Which RT will you add? Can you forecast which RT will cause the overwhelming VPN routes?

> 
> I really fail to see any reason to define a new protocol extension for a functionality which is already readily available with exactly the same functionality. In fact the new RT value can be even identical to RD numerical value if you already use RD per VRF. 
> 
> This will do everything you need to do in terms of fine protection plus it will also not require any single line of implementation. 
> 

[WAJ] Welcome your other comments. Please do not loop around RTC(we have explained several times, also in updated draft. Please see  https://tools.ietf.org/html/draft-wang-idr-rd-orf-03#section-1

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Aug 2020 14:46:35 +0200

Hi Aijun,

> RTC can be deployed in all inter-as options.

> [WAJ] Which RT will you add? Can you forecast which RT will cause the

You would add RT numerically identical to your local VRF RD. You will not
use it for import. You will *only* use it to signal which src VRF is
"overwhelming" your network and such routes will be filtered at src.
Exactly as you are asking.

[WAJ] Welcome your other comments. Please do not loop around RTC(we have
> explained several times, also in updated draft. Please see
> https://tools.ietf.org/html/draft-wang-idr-rd-orf-03#section-1
>

   1) Route Target Constraint

   RTC can only filter the VPN routes from the uninterested VRFs, if the
   "trashing routes" come from the interested VRF, filter on RTs will
   erase all prefixes from this VRF.

Your explanation is incorrect or at best incomplete. You can use RT as any
other community to color the routes.  Export RT and import RT are
completely independent functionality.

To reiterate: you export your routes with one additional RT (equal to local
RD). You import routes as today - no change. So when some imported routes
are detected to be "overwhelming" you just take the new RT and signal it
with RTC to stop src (or RR) sending those to you in EXACTLY same way you
would use RD for such filtering.

It is so basic ...

Cheers,
R.

---

From: Aijun Wang <[email-masked]>
Date: Fri, 28 Aug 2020 21:15:27 +0800

Hi, Robert:
I see the shadow of RD-ORF mechanism from your usage of additional RT.
If we have defined RD that associated with the prefixes, why we define another RT to accomplish the same task?
And, the RT information within RTC message just tell the upstream router it want the routes with such RT——Adding the additional RT that you mentioned seems get the contrary results as that wanted via RD-ORF?

Aijun Wang
China Telecom

> On Aug 28, 2020, at 20:46, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Aijun,
>  
> You would add RT numerically identical to your local VRF RD. You will not use it for import. You will *only* use it to signal which src VRF is "overwhelming" your network and such routes will be filtered at src. Exactly as you are asking. 
> 
> 
> Your explanation is incorrect or at best incomplete. You can use RT as any other community to color the routes.  Export RT and import RT are completely independent functionality. 
> 
> To reiterate: you export your routes with one additional RT (equal to local RD). You import routes as today - no change. So when some imported routes are detected to be "overwhelming" you just take the new RT and signal it with RTC to stop src (or RR) sending those to you in EXACTLY same way you would use RD for such filtering. 
> 
> It is so basic ... 
> 
> Cheers,
> R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Aug 2020 16:21:43 +0200

Hi,

Because we have all mechanisms in place to signal and filter RTs.

And we do not have similar mechanisms to signal between PE, RRs, inter-as
etc ... Adding this seems not a trivial change to the number of BGP
implementations.

Note pls that I am just trying to help you to achieve the required
functionality reusing existing protocol implementations not creating any
shadows.

Kind regards,
R.

On Fri, Aug 28, 2020 at 3:15 PM Aijun Wang <[email-masked]>
wrote:

> And, the RT information within RTC message just tell the upstream router
> it want the routes with such RT——Adding the additional RT that you
> mentioned seems get the contrary results as that wanted via RD-ORF?
>
>
> Aijun Wang
> China Telecom
>
> To reiterate: you export your routes with one additional RT (equal to
> local RD). You import routes as today - no change. So when some imported
> routes are detected to be "overwhelming" you just take the new RT and
> signal it with RTC to stop src (or RR) sending those to you in EXACTLY same
> way you would use RD for such filtering.
>
> It is so basic ...
>
> Cheers,
> R.
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 31 Aug 2020 23:38:57 -0400

> Exactly as you are asking.

    Gyan> Understood so similar additive RT used traditionally for bleeding
routes or hub/spoke style have the VRFs on each PE have a 2nd RT defined on
each VRF defined on each VRF on each PE.  So that 2nd RT would represent
all routes in the VRF, same as the first RT, so it would filter at RT level
all routes within a VRF and not source PE originating the routes as would
happen with RD-ORF at RD source PE originating the flood.  Another idea
would be difficult but you could match on a special standard flood
communities created or match on prefixes for the 2nd RT so the 2nd RT now
represents all routes being sourced from the PE that is causing the flood.
This would be a very manual process but once you have the 2nd RT defined to
represent the locally originated routes from each PE you can now apply and
RT import policy on any PE to block the trashing routes.  Imagine if you
have 1000s of VPNs defined on each PE.  Quite complicated.

> way you would use RD for such filtering.

   Gyan> I think what Aijun was trying to say which needed rewriting of the
verbiage is that by default all all PEs have “RT Filtering” enabled by
default so if you don’t have an explicit import on an RT the PE drops the
vpn prefixes coming from the RR.  So RTC is quite powerful in that it can
be more efficient and optimized as far as RT distribution graph with the RT
membership ORF rib-out on PE-RR intra-as instead of advertising all what
Aijun called “uninteresting” RTs in the reverse direction the RR only
advertises the RTs being imported on the PEs.  Intra-AS RTC cuts down on
default all RT advertisements and it most advantageous in sparse RT
distribution graph.  RTC can also be very handy inter-as as well as we have
agreed which allows the inter as options B and AB and even some cases C to
be more plausible between administrative domains using the RTC membership
to cut down on advertisement of RTs not being imported between domains.  So
with this draft RD-ORF provides a layer of granularity at the RD origin PE
advertising the flood of prefixes layer and can be deployed both inter and
intra domain.  This makes the inter-as option B and C more viable between
administrative domains.  Option AB does have resolves the Option A BGP
control plane scalability issue but with the added separation of data plane
isolation in this AB hybrid model it requires having an interface or sub
interface per VRF so that does become challenging if you have 1000s of
VPNs.  So this draft along with use of RTC and all other controls in place
makes Option B and C viable as now you have that origin PE RD offender
granularity to mitigate floods.

*Gyan Mishra*