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

From: "[email-masked]" <[email-masked]>
Date: Mon, 24 Aug 2020 09:51:00 +0800

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

[email-masked]
 
From: internet-drafts
Date: 2020-08-24 09:43
To: Haibo Wang; Gyan S. Mishra; Wei Wang; Aijun Wang; Shunwan Zhuang; Jie Dong; Gyan Mishra
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

---

From: "Fomin, Sergey (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 24 Aug 2020 20:28:01 +0000

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.

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.

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

Abstract:

The IETF Secretariat

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 24 Aug 2020 21:43:38 +0000

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,

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

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

Best Regards.

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:

The IETF Secretariat

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 25 Aug 2020 10:11:52 +0800

Hi Sergey and Jim,

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

Best Regards,

Wei Wang
China Telecom

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

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

Hi IDR experts,

Best Regards.

Wei Wang
China Telecom
 
[email-masked]
 
From: internet-drafts
Date: 2020-08-24 09:43

 
Abstract:

 
 
The IETF Secretariat

---

From: "Fomin, Sergey (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 25 Aug 2020 20:57:03 +0000

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,

Best Regards,

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,

--
Sergey

Hi IDR experts,

Best Regards.

Abstract:

The IETF Secretariat

---

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

In-line

Kind Regards

Gyan

On Mon, Aug 24, 2020 at 4:28 PM Fomin, Sergey (Nokia - US/Mountain View) <
[email-masked]> wrote:

> 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 <[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,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>    -
>    -
>    -
> ------------------------------
>
>
>
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>
> 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:
>
>
>
>
>
>
> _______________________________________________
>
> Idr mailing list
>
> [email-masked]
>
> 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