Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

From: "Aijun Wang" <[email-masked]>
Date: Wed, 5 Aug 2020 10:34:41 +0800

Hi, Keyur, Praveen and Robert:

Thanks for your comments on this draft during the IETF 108 meeting.  

Below are responses for your questions, please review them to see whether they resolve your concerns:

【Q-Praveen】: When PE1 injects a prefix, will it impact other routers which are not overflowing the source?

【A-WAJ】：No. RR can control when to send the RD-ORF message to the upstream/source router. 

For example, if only one PE overflow, RR can add the RD-ORF as its Adj-RIB-Out filter to this PE, and don’t send this message to the source PE, or other RR.

Theoretically, RR need only send such RD-ORF upstream when it can’t process the BGP Updates, or it is overflow. 

【Keyur】：The prefix filter level filtering has more expense than a higher level filters.

【A-WAJ】：RD based filter is also higher level filter.  RT based filter can’t solve the problems that described in this draft.

【Robert】: there was a number of technical problems sent to the list. None of these were addressed. This is not the right way to filter VPN

【A-WAJ】：Would you like to point out which technical problem isn’t addressed yet?  We have also compared the existing solutions and their limitations in the draft and at the presentation.

Best Regards

Aijun Wang

China Telecom 

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, July 28, 2020 4:47 PM
To: idr <[email-masked]>
Subject: [Idr] New Version Notification for draft-wang-idr-rd-orf-01.txt

Hi,IDR experts:

    Based on the previous discussion with Robert and Jakob, we update our draft as follows:

·       The differences between RD-ORF, RTC and Address Prefix ORF are briefly described;

·       The encoding of RD-ORF type-specific part is changed and the source address sub TLV field is added;

·       The application in single-domain scenario is added;

·       Four new types of sub-TLV are defined to carry the source address in different scenarios.

    Any comments are welcome.

Best Regards.

  _____  

 王巍  Wang Wei    

+86-010-5090-2397  
+86-177-7809-6050  
[email-masked] <mailto:[email-masked]>   
------------------------------------------------------------------------  
CTNET2025研究所  
中国电信股份有限公司北京研究院  
China Telecom Corporation Limited Beijing Research Institute  
北京市昌平区北七家镇未来科技城南区中国电信北京信息科技创新园  
邮编：102209 

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

Date: 2020-07-28 16:17

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

Subject: New Version Notification for draft-wang-idr-rd-orf-01.txt

A new version of I-D, draft-wang-idr-rd-orf-01.txt

has been successfully submitted by Wei Wang and posted to the

IETF repository.

Name: draft-wang-idr-rd-orf

Revision: 01

Title: Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4

Document date: 2020-07-28

Group: Individual Submission

Pages: 14

URL:            https://www.ietf.org/internet-drafts/draft-wang-idr-rd-orf-01.txt

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

Htmlized:       https://tools.ietf.org/html/draft-wang-idr-rd-orf-01

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

Diff:           https://www.ietf.org/rfcdiff?url2=draft-wang-idr-rd-orf-01

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 infomation directly (e.g. routers

   in single-domain connect via Route Reflector, or routers in Option B/

   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: Robert Raszuk <[email-masked]>
Date: Wed, 5 Aug 2020 08:54:54 +0200

Hello Aijun,

【Robert】: there was a number of technical problems sent to the list. None
of these were addressed. This is not the right way to filter VPN

【A-WAJ】：Would you like to point out which technical problem isn’t addressed
yet?  We have also compared the existing solutions and their limitations in
the draft and at the presentation.

As you know VPNs use different scheme of RD allocations. Most common would
be to import RDs with local rewrite. So I know you realize that and your
intention is to signal such RD to RRs or other PEs from the pre imported
routes. So far so good.

Now realize that on a given PE there is few VRFs which need to import given
RD. Import is based on RTs. Therefor not all target VRFs may import same
subset of routes originally carrying given RD. One VRF can import 5 routes,
the other 10 and yet one more 10000. Let's assume for now that that last
VRF "overflows" and decided to trigger RD-ORF.

That means that PE signals this to RR and RR stops sending all such routes
to given PE. That effectively means that even those first two VRFs which
are fine as they just import subset of routes suffer unreachability as
those routes are simply no longer arriving at the PE.

For me this is showstopper - and pretty fatal one to use RD for filtering.
We do import based on RTs and filtering should also be done based on the
RTs.

- - -

My other serious concern is that end customer will in no one be notified
about such RD-ORF filtering ... - that is frankly not acceptable to me or
to any L3VPN or L2VPN customer. As comparison when you use prefix limit on
the PE-CE customer's session goes down hence customer is alerted about the
problem.

See worst "solutions" are those which may cause silent failures. We should
avoid those at all cost.

- - -

Last this is measure to protect SP resources (PEs). Let me observe that
this topic came up in early 2000 and it was commonly agreed that the best
we can offer is protect the network from any customer injecting more then
in the customer <--> SP SLAs.

Beyond that SP's infra must keep good monitoring of PE resources instead of
waiting for disaster to happen and building parachutes.

Kind regards,

R.

On Wed, Aug 5, 2020 at 4:34 AM Aijun Wang <[email-masked]> wrote:

> For example, if only one PE overflow, RR can add the RD-ORF as its
> Adj-RIB-Out filter to this PE, and don’t send this message to the source
> PE, or other RR.
>
> Theoretically, RR need only send such RD-ORF upstream when it can’t
> process the BGP Updates, or it is overflow.
>
>
>
> 【A-WAJ】：RD based filter is also higher level filter.  RT based filter
> can’t solve the problems that described in this draft.
>
>
>
> 【Robert】: there was a number of technical problems sent to the list. None
> of these were addressed. This is not the right way to filter VPN
>
> 【A-WAJ】：Would you like to point out which technical problem isn’t
> addressed yet?  We have also compared the existing solutions and their
> limitations in the draft and at the presentation.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* Tuesday, July 28, 2020 4:47 PM
> *To:* idr <[email-masked]>
> *Subject:* [Idr] New Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> Hi,IDR experts:
>
>
>
> ------------------------------
>
>  王巍  Wang Wei
>
> +86-010-5090-2397
> +86-177-7809-6050
> [email-masked]
> *From:* internet-drafts <[email-masked]>
>
> *Date:* 2020-07-28 16:17
>
> *To:* Jie Dong <[email-masked]>; Aijun Wang <[email-masked]>;
> Shunwan Zhuang <[email-masked]>; Wei Wang
> <[email-masked]>; Haibo Wang <[email-masked]>
>
> *Subject:* New Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-wang-idr-rd-orf-01.txt
>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf
>

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 5 Aug 2020 15:44:32 +0800

Hi, Robert:

Thanks for your comments.  Please see the detail responses inline.

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Wednesday, August 5, 2020 2:55 PM
To: Aijun Wang <[email-masked]>
Cc: Keyur Patel <[email-masked]>; idr <[email-masked]>; [email-masked]
Subject: Re: [Idr][Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Hello Aijun,

As you know VPNs use different scheme of RD allocations. Most common would be to import RDs with local rewrite. So I know you realize that and your intention is to signal such RD to RRs or other PEs from the pre imported routes. So far so good. 

Now realize that on a given PE there is few VRFs which need to import given RD. Import is based on RTs. Therefor not all target VRFs may import same subset of routes originally carrying given RD. One VRF can import 5 routes, the other 10 and yet one more 10000. Let's assume for now that that last VRF "overflows" and decided to trigger RD-ORF. 

That means that PE signals this to RR and RR stops sending all such routes to given PE. That effectively means that even those first two VRFs which are fine as they just import subset of routes suffer unreachability as those routes are simply no longer arriving at the PE. 

[WAJ] Route Import is based on RTs, but different VRFs on one PE will use different RDs(and also different import RTs). Then filter based on RD will not influence the route import in another VRF, especially within the same PE.

For me this is showstopper - and pretty fatal one to use RD for filtering. We do import based on RTs and filtering should also be done based on the RTs. 

[WAJ] RT can’t be uniquely to identify one specified VPN. 

My other serious concern is that end customer will in no one be notified about such RD-ORF filtering ... - that is frankly not acceptable to me or to any L3VPN or L2VPN customer. As comparison when you use prefix limit on the PE-CE customer's session goes down hence customer is alerted about the problem. 

See worst "solutions" are those which may cause silent failures. We should avoid those at all cost. 

[WAJ] The RD-ORF message is initiated from the overflow PE.  The RR or the source of VPN overflow act based on the instruction from the applier. Then this is not silent failures.

Last this is measure to protect SP resources (PEs). Let me observe that this topic came up in early 2000 and it was commonly agreed that the best we can offer is protect the network from any customer injecting more then in the customer <--> SP SLAs. 

Beyond that SP's infra must keep good monitoring of PE resources instead of waiting for disaster to happen and building parachutes. 

[WAJ] RD-ORF just want to keep the disaster as small as possible, based on the parachutes J

Kind regards,

R.

 

 

 

 

On Wed, Aug 5, 2020 at 4:34 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

 

Best Regards

Aijun Wang

China Telecom 

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of [email-masked] <mailto:[email-masked]> 
Sent: Tuesday, July 28, 2020 4:47 PM
To: idr <[email-masked] <mailto:[email-masked]> >
Subject: [Idr] New Version Notification for draft-wang-idr-rd-orf-01.txt

Hi,IDR experts:

Best Regards.

  _____  

 王巍  Wang Wei    

+86-010-5090-2397  
+86-177-7809-6050  
[email-masked]  

Date: 2020-07-28 16:17

IETF repository.

Revision: 01

Pages: 14

Abstract:

                                                                                  

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

The IETF Secretariat

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 5 Aug 2020 11:54:31 +0000

Aijun,

Pls see inline ,

How so? Based on the excerpt from section 5, it seems clear that  RD-ORF would cause an outage for all VRFs that import one or more routes matching the RD.

//

Before sending a VPN route (the RD is equal to RD1) toward PE1, PE2
   will check its Adj-RIB-out and find the RD-ORF entry prevent it from
   sending VPN route which carries RD1 to RR2.  Then, PE2 will stop
   sending that VPN route.

//

Cheers,
Rajiv

On Aug 5, 2020, at 3:48 AM, Aijun Wang <[email-masked]> wrote:

Hi, Robert:

Hello Aijun,

Last this is measure to protect SP resources (PEs). Let me observe that this topic came up in early 2000 and it was commonly agreed that the best we can offer is protect the network from any customer injecting more then in the customer <--> SP SLAs.
Beyond that SP's infra must keep good monitoring of PE resources instead of waiting for disaster to happen and building parachutes.
[WAJ] RD-ORF just want to keep the disaster as small as possible, based on the parachutes ☺

Kind regards,
R.

On Wed, Aug 5, 2020 at 4:34 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Keyur, Praveen and Robert:

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, July 28, 2020 4:47 PM
To: idr <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] New Version Notification for draft-wang-idr-rd-orf-01.txt

Hi,IDR experts:

    Based on the previous discussion with Robert and Jakob, we update our draft as follows:
•       The differences between RD-ORF, RTC and Address Prefix ORF are briefly described;
•       The encoding of RD-ORF type-specific part is changed and the source address sub TLV field is added;
•       The application in single-domain scenario is added;
•       Four new types of sub-TLV are defined to carry the source address in different scenarios.
    Any comments are welcome.

Best Regards.
________________________________
 王巍  Wang Wei
+86-010-5090-2397
+86-177-7809-6050
[email-masked]<mailto:[email-masked]>
------------------------------------------------------------------------
CTNET2025研究所
中国电信股份有限公司北京研究院
China Telecom Corporation Limited Beijing Research Institute
北京市昌平区北七家镇未来科技城南区中国电信北京信息科技创新园
邮编：102209

From: internet-drafts<mailto:[email-masked]>
Date: 2020-07-28 16:17
To: Jie Dong<mailto:[email-masked]>; Aijun Wang<mailto:[email-masked]>; Shunwan Zhuang<mailto:[email-masked]>; Wei Wang<mailto:[email-masked]>; Haibo Wang<mailto:[email-masked]>
Subject: New Version Notification for draft-wang-idr-rd-orf-01.txt

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]
https://www.ietf.org/mailman/listinfo/idr

---

From: Aijun Wang <[email-masked]>
Date: Wed, 5 Aug 2020 22:04:15 +0800

Hi, Rajiv:
If RD is allocated as per VRF per PE, the overflow VRF on one PE will find the source RD(also source VRF on source PE) that leads to the overflow. 
Only the routes that carry this specified RD will be suppressed. It will not influence other VRFs on the overflow PE, because there is no other VRF sourcing the routes that carry the same RD.
If not, there will be VPN prefix collision.

If the RD is allocated as per VRF only, that is to say, same VRF( corresponding to same VPN/Customer) on different PE use the same RD, the filter entry should also consider the source PE.

We have updated the encoding of RD-ORF message in the latest version. Section 5 that you referenced should also be updated.
Thanks for your review and comments.

Aijun Wang
China Telecom

> On Aug 5, 2020, at 19:54, Rajiv Asati (rajiva) <[email-masked]> wrote:
> 
> 
> Aijun,
> 
> Pls see inline , 
> 
>> From: internet-drafts
>> To: Jie Dong; Aijun Wang; Shunwan Zhuang; Wei Wang; Haibo Wang

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Aug 2020 17:35:01 +0200

Aijun,

*[WAJ] Route Import is based on RTs, but different VRFs on one PE will use
> different RDs(and also different import RTs). Then filter based on RD will
> not influence the route import in another VRF, especially within the same
> PE.*
>

That is incorrect.

When you filter VPNv4 routes based on the RD you are suppressing this route
say on remote PE or RR such that it will never arrive on the PE.

And please kindly observe that VPNv4 routes carry a lot of RTs attached. So
one VRF may import this route based on the RT1 and the other may import the
same route based on the presence of RT2.

That means that healthy VRF may no longer be able to import this route when
you suppress it upstream in spite of the fact that there is no problem with
overflow on a given VRF.

Your scheme could work if we would assume no extranets nor more then one RT
per VPNv4 route. But this is not the case in the specification nor in any
deployment I have seen or run.

> *[WAJ] RT can’t be uniquely to identify one specified VPN.*
>

It sure can. Just add one more RT to identify the VPN on export. You may
not even ever import that RT anywhere. It would be used just as a VPN-ID in
your network.

> *[WAJ] The RD-ORF message is initiated from the overflow PE.  The RR or
> the source of VPN overflow act based on the instruction from the applier.
> Then this is not silent failures.*
>

There is no such a thing like an overflow PE. PE has different RIBs usually
one per VRF. So ultimately the overflow is coming from a VRF. And as we
proven that is not possible to avoid based on the RD filtering without
affecting other VRFs.

It is a silent failure for customers as customers never see the RD-ORF.

I would be willing to state that it may be better to fail such overflown PE
other then trying to recover and keep it running on the clif by shaving of
VPN routes arrving to it. Either such PE needs replacement or operator
running such PE needs to update his resume.

> *[WAJ] RD-ORF just want to keep the disaster as small as possible, based
> on the parachutes **J*
>

We are here to avoid silent disasters. Or when it happens make a big enough
boom.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Aug 2020 17:40:41 +0200

> If RD is allocated as per VRF per PE, the overflow VRF on one PE will
find the source RD(also source VRF on source PE) that leads to the
overflow.

That is not the point.

The point is that such RD allocation still allows the routes generated by
such VRF to be selectively imported by different VRFs on the same (or
different) destination PE.

Some may import 5 routes some may import 1000.

More to it are you familiar with export map for RTs ? With that same RD
routes may carry completely different set of RTs - feature used very often.

You scheme breaks flat all of this. Very sorry but we just can not allow to
proceed this any further here nor in BESS.

Regards,
R.

PS. Yes I completely agree that your proposal may work fine in specific
deployments. But we are here to make sure it works in all deployments by
analyzing corner cases. That what makes protocol design both fun and a
challenge. Your proposal unfortunately does not work well in most real
deployments.

On Wed, Aug 5, 2020 at 4:04 PM Aijun Wang <[email-masked]> wrote:

> Hi, Rajiv:
> If RD is allocated as per VRF per PE, the overflow VRF on one PE will find
> the source RD(also source VRF on source PE) that leads to the overflow.
> Only the routes that carry this specified RD will be suppressed. It will
> not influence other VRFs on the overflow PE, because there is no other VRF
> sourcing the routes that carry the same RD.
> If the RD is allocated as per VRF only, that is to say, same VRF(
> corresponding to same VPN/Customer) on different PE use the same RD, the
> filter entry should also consider the source PE.
>
> We have updated the encoding of RD-ORF message in the latest version.
> Section 5 that you referenced should also be updated.
> How so? Based on the excerpt from section 5, it seems clear that  RD-ORF
> would cause an outage for all VRFs that import one or more routes matching
> the RD.
>
> //
>
>
> *From:* Robert Raszuk [mailto:[email-masked]]
> *Sent:* Wednesday, August 5, 2020 2:55 PM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* Keyur Patel <[email-masked]>; idr <[email-masked]>;
> [email-masked]
> *Subject:* Re: [Idr][Responses for the comments during the IETF108] New
> Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> Hello Aijun,
>
>
>
> Now realize that on a given PE there is few VRFs which need to import
> given RD. Import is based on RTs. Therefor not all target VRFs may import
> same subset of routes originally carrying given RD. One VRF can import 5
> routes, the other 10 and yet one more 10000. Let's assume for now that that
> last VRF "overflows" and decided to trigger RD-ORF.
>
> *[WAJ] RT can’t be uniquely to identify one specified VPN. *
>
> Beyond that SP's infra must keep good monitoring of PE resources instead
> of waiting for disaster to happen and building parachutes.
>
> 【A-WAJ】：RD based filter is also higher level filter.  RT based filter can’t
> solve the problems that described in this draft.
>
>
>

---

From: Aijun Wang <[email-masked]>
Date: Thu, 6 Aug 2020 00:08:59 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Aug 5, 2020, at 23:35, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Aijun,
> 
> When you filter VPNv4 routes based on the RD you are suppressing this route say on remote PE or RR such that it will never arrive on the PE. 
> 
> And please kindly observe that VPNv4 routes carry a lot of RTs attached. So one VRF may import this route based on the RT1 and the other may import the same route based on the presence of RT2. 

[WAJ] The VPN routes imported in these VRFs can’t use the same RD, or else, the VPN prefixes in different VRFs will collision on RR.

> 
> That means that healthy VRF may no longer be able to import this route when you suppress it upstream in spite of the fact that there is no problem with overflow on a given VRF. 
> 
> Your scheme could work if we would assume no extranets nor more then one RT per VPNv4 route. But this is not the case in the specification nor in any deployment I have seen or run. 

[WAJ]  We have no any assumption on RT allocation.
> It sure can. Just add one more RT to identify the VPN on export. You may not even ever import that RT anywhere. It would be used just as a VPN-ID in your network. 

[WAJ] Don’t you agree that such usage of RT is same as RD?

> There is no such a thing like an overflow PE. PE has different RIBs usually one per VRF. So ultimately the overflow is coming from a VRF. And as we proven that is not possible to avoid based on the RD filtering without affecting other VRFs. 

[WAJ] Will not affect other VRFs, as explained above.

> I would be willing to state that it may be better to fail such overflown PE other then trying to recover and keep it running on the clif by shaving of VPN routes arrving to it. Either such PE needs replacement or operator running such PE needs to update his resume. 
>  

[WAJ] Maybe it is not the overflown PE should be blamed?
> We are here to avoid silent disasters. Or when it happens make a big enough boom. 

[WAJ] The overflown VRF/PE can log its state and then make this big enough boom?

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Aug 2020 18:14:13 +0200

> [WAJ] The VPN routes imported in these VRFs can’t use the same RD, or
> else, the VPN prefixes in different VRFs will collision on RR.
>

Nothing will "collide" on RRs.

NLRI = RD+Prefix  not just the RD.

So you may have completely different prefixes sourced by the same VRF going
to completely different VRFs on same or different PEs.

Kind regards,
R.

---

From: Aijun Wang <[email-masked]>
Date: Thu, 6 Aug 2020 00:17:32 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Aug 5, 2020, at 23:40, Robert Raszuk <[email-masked]> wrote:
> 
> 
> The point is that such RD allocation still allows the routes generated by such VRF to be selectively imported by different VRFs on the same (or different) destination PE. 

[WAJ] The VPN routes in different VRF will not use the same RD, or else, these VPN routes will collision on RR.

> More to it are you familiar with export map for RTs ? With that same RD routes may carry completely different set of RTs - feature used very often. 

[WAJ] Hub-Spoke VPN topology. But these sites are in same VPN/VRF, then they can use the same RD. 
In such case, the source router information should also be used in the filter action. We have updated the encoding of RD-VRF to include this information.

> 
> You scheme breaks flat all of this. Very sorry but we just can not allow to proceed this any further here nor in BESS. 
> 
> Regards,
> R.
> 
> PS. Yes I completely agree that your proposal may work fine in specific deployments. But we are here to make sure it works in all deployments by analyzing corner cases. That what makes protocol design both fun and a challenge. Your proposal unfortunately does not work well in most real deployments.  
> 
[WAJ] Would you like to illustrate the scenarios that this mechanism can’t work?

---

From: Aijun Wang <[email-masked]>
Date: Thu, 6 Aug 2020 00:48:42 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Aug 6, 2020, at 00:14, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 

[WAJ] The prefix part can be overlap in different VRF. If the RD is same, RD+Prefix will also be overlap.
We must make sure different VRF use different RD to make the VPN prefixes unique within the domain.
> 
> So you may have completely different prefixes sourced by the same VRF going to completely different VRFs on same or different PEs. 
> 

[WAJ] This situation is for extraVPN communication, and should be designed carefully to avoid the address collision. 
If the address space in different VRF need to be considered in such manner, putting them in one VRF may be more straightforward.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 6 Aug 2020 05:41:25 -0400

Hi Aijun

I agree with Robert that you cannot filter by RD or you would drop all the
routes and filtering must be done by RT.  Also the issue with RT ORF filter
is as Robert mentioned that you may have the same prefix with two different
RTs which is common unique by RD and so the ORF would drop the prefixes.

I am not sure I understand what problem you are trying to solve that is not
already solved by RTC membership so that only RTs imported by the PE are
what is advertised by the RR.  That is most effective way of cutting down
the RT flooding that occurs in the RR to PE advertisement.  RT filtering is
enabled by Default on all PEs and only if the RT is imported on the PE are
the RTs accepted into the vpn rib. That works pretty well in cutting down
RT advertisements by the RR.

As Robert mentioned each VRF has a maximum prefix which is defined on the
PE RIBs per VRF and in general on most current or even hardware within the
last 10 years is a minimum 1M prefixes per VRF is pretty standard with most
vendors and platforms.  The vpn rib limit is much much higher on the higher
end platforms.

You draft talks about inter-as issues solved with RT-ORF.  So when PE-PE
inter-as option B by default all RTs are dropped due to default RT
filtering and only RTs that are accepted are those RTS that are explicitly
being imported on the PE ASBR.  There is an option for retain route-target
all that disabled the default RT filtering so that all VPN routes can be
accepted on the inter-as option B link.  However a RT filter can still be
applied to the retian-route-target all so that only pertinent RTs are
accepted inter domain.  That seems to work pretty well.

As far as inter-as option C, the PE-PE ASBRs do not maintain the VPN RIB.
BGP LU is enabled on the inter-as link for end to end LSP by importing the
loopback between ASs for the end to end LSPto be built.   The RRs between
the SPs have eBGP VPN IPv4 VPN IPV6 peer with next hop unchanged so the
data plane gets built between the PEs.  The RR by default does not have RT
filtering enabled by default as does the PE, so is able to reflect all the
vpn routes learned to all PEs within each AS.  In the inter-as scenario as
well RTC works very well with the RT membership to cut down on RR to PE vpn
route advertisements.

Kind Regards

Gyan

On Wed, Aug 5, 2020 at 12:49 PM Aijun Wang <[email-masked]>
wrote:

> So you may have completely different prefixes sourced by the same VRF
> going to completely different VRFs on same or different PEs.
>
>
> [WAJ] This situation is for extraVPN communication, and should be designed
> carefully to avoid the address collision..
> If the address space in different VRF need to be considered in such
> manner, putting them in one VRF may be more straightforward.
>
> Kind regards,
> R.
>
>
>
>
>
>
>
-- 

<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: Thu, 6 Aug 2020 11:49:13 +0200

Hi Gyan,

Thank you for your comments - all very valid observations.

Just to perhaps clarify one thing ... Problem authors are attempting to
address - the way I understand it - is that given resource may be suffering
from actually legitimate VPN routes hence to use RTC indeed a lot of
additional RTs would have to be applied.

But I do not understand why authors fail to recognize that solution for
their problem has been invented and implemented over 20 years ago already.
The solution is to control on a per *ingress* VRF basis number of VPN
routes customer is authorized to inject into his VPN with eBGP PE-CE prefix
limit.

Most SPs offering L3VPNs use prefix limit successfully to protect their
shared resources for vast majority of customers and deployments. For VPN
customers with unpredictable amount of routing CSC model should be used
instead.

By all means filtering and dropping accepted into SP network VPN route
should not take place.

Thx,
R.

On Thu, Aug 6, 2020 at 11:41 AM Gyan Mishra <[email-masked]> wrote:

> I am not sure I understand what problem you are trying to solve that is
> not already solved by RTC membership so that only RTs imported by the PE
> are what is advertised by the RR.  That is most effective way of cutting
> down the RT flooding that occurs in the RR to PE advertisement.  RT
> filtering is enabled by Default on all PEs and only if the RT is imported
> on the PE are the RTs accepted into the vpn rib. That works pretty well in
> cutting down RT advertisements by the RR.
>
>> [WAJ] This situation is for extraVPN communication, and should be
>> designed carefully to avoid the address collision..

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 6 Aug 2020 06:02:30 -0400

Hi Robert

I am in agreement as you stated that most service providers from my
experience use the per VRF prefix limit to protect resources.  Problem
solved as you said 20+ years ago.

That is a general rule of thumb for any service providers to perform due
diligence on their PE memory resource carving per VRF and set it
appropriately based on platform and total number of VRFs to account for.

Problem solved on the SP end.

On the customer end, they can also use the maximum prefix peer command as
well to prevent flood of routes in case of unwanted advertisements from
unintentional VRF leaking by providers.

Kind Regards

Gyan

On Thu, Aug 6, 2020 at 5:49 AM Robert Raszuk <[email-masked]> wrote:

>> I agree with Robert that you cannot filter by RD or you would drop all
>> the routes and filtering must be done by RT.  Also the issue with RT ORF
>> filter is as Robert mentioned that you may have the same prefix with two
>> different RTs which is common unique by RD and so the ORF would drop the
>> prefixes.
>>
>> As far as inter-as option C, the PE-PE ASBRs do not maintain the VPN
>> RIB.  BGP LU is enabled on the inter-as link for end to end LSP by
>> importing the loopback between ASs for the end to end LSPto be built.   The
>> RRs between the SPs have eBGP VPN IPv4 VPN IPV6 peer with next hop
>> unchanged so the data plane gets built between the PEs.  The RR by default
>> does not have RT filtering enabled by default as does the PE, so is able to
>> reflect all the vpn routes learned to all PEs within each AS.  In the
>> inter-as scenario as well RTC works very well with the RT membership to cut
>> down on RR to PE vpn route advertisements.
>>
>> Kind Regards
>>
>> Gyan
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> --

*Gyan Mishra*

---

From: Aijun Wang <[email-masked]>
Date: Thu, 6 Aug 2020 19:29:35 +0800

Hi, Gyan and Robert:

Maximum Prefix Limit is one method to control the routes between PE and CE, but we should not depend only on it. 

RD-ORF can limit the influence scope of misbehavior PE as small as possible.

RT-ORF can suppress the routes from unwanted VRFs, but can’t suppress the overflow routes in VRF that it is interested.

More details responses are inline below.

Aijun Wang
China Telecom

> On Aug 6, 2020, at 18:02, Gyan Mishra <[email-masked]> wrote:
> 
> 
> 
> Hi Robert 
> 
> I am in agreement as you stated that most service providers from my experience use the per VRF prefix limit to protect resources.  Problem solved as you said 20+ years ago.  
> 
> That is a general rule of thumb for any service providers to perform due diligence on their PE memory resource carving per VRF and set it appropriately based on platform and total number of VRFs to account for.  
> 
> On the customer end, they can also use the maximum prefix peer command as well to prevent flood of routes in case of unwanted advertisements from unintentional VRF leaking by providers.
> 
> Kind Regards 
> 
> Gyan
>  
> 
>> Just to perhaps clarify one thing ... Problem authors are attempting to address - the way I understand it - is that given resource may be suffering from actually legitimate VPN routes hence to use RTC indeed a lot of additional RTs would have to be applied. 
>> 
>> But I do not understand why authors fail to recognize that solution for their problem has been invented and implemented over 20 years ago already. The solution is to control on a per *ingress* VRF basis number of VPN routes customer is authorized to inject into his VPN with eBGP PE-CE prefix limit. 

[WAJ] we have mentioned prefix limit solutions in the draft and analysis its applicability scope.
>> 
>> Most SPs offering L3VPNs use prefix limit successfully to protect their shared resources for vast majority of customers and deployments. For VPN customers with unpredictable amount of routing CSC model should be used instead. 
>> 
>> By all means filtering and dropping accepted into SP network VPN route should not take place. 
>> 
>> Thx,
>> R.
>> 
>> 
>> 
>> 
>> 
>>> I agree with Robert that you cannot filter by RD or you would drop all the routes and filtering must be done by RT.  Also the issue with RT ORF filter is as Robert mentioned that you may have the same prefix with two different RTs which is common unique by RD and so the ORF would drop the prefixes.  

[WAJ] Such situation can only happen at the extraVPN scenarios which should be designed carefully——one must keep the prefixes in these VRFs not overlap. But if the prefixes in these VRFs are not overlap, why do we need to separate them in different VRFs?
In conclusion, this is just corner case and should be avoided in design.

>>> 
>>> I am not sure I understand what problem you are trying to solve that is not already solved by RTC membership so that only RTs imported by the PE are what is advertised by the RR.  That is most effective way of cutting down the RT flooding that occurs in the RR to PE advertisement.  RT filtering is enabled by Default on all PEs and only if the RT is imported on the PE are the RTs accepted into the vpn rib. That works pretty well in cutting down RT advertisements by the RR.
>>> 
>>> As Robert mentioned each VRF has a maximum prefix which is defined on the PE RIBs per VRF and in general on most current or even hardware within the last 10 years is a minimum 1M prefixes per VRF is pretty standard with most vendors and platforms.  The vpn rib limit is much much higher on the higher end platforms.
>>> 
>>> You draft talks about inter-as issues solved with RT-ORF.  So when PE-PE inter-as option B by default all RTs are dropped due to default RT filtering and only RTs that are accepted are those RTS that are explicitly being imported on the PE ASBR.  There is an option for retain route-target all that disabled the default RT filtering so that all VPN routes can be accepted on the inter-as option B link.  However a RT filter can still be applied to the retian-route-target all so that only pertinent RTs are accepted inter domain.  That seems to work pretty well.
>>> 
>>> As far as inter-as option C, the PE-PE ASBRs do not maintain the VPN RIB.  BGP LU is enabled on the inter-as link for end to end LSP by importing the loopback between ASs for the end to end LSPto be built.   The RRs between the SPs have eBGP VPN IPv4 VPN IPV6 peer with next hop unchanged so the data plane gets built between the PEs.  The RR by default does not have RT filtering enabled by default as does the PE, so is able to reflect all the vpn routes learned to all PEs within each AS.  In the inter-as scenario as well RTC works very well with the RT membership to cut down on RR to PE vpn route advertisements.
>>> 
>>> Kind Regards 
>>> 
>>> Gyan
>>> 
>>>> On Wed, Aug 5, 2020 at 12:49 PM Aijun Wang <[email-masked]> wrote:
>>>> Hi, Robert:
>>>> 
>>>> Aijun Wang
>>>> China Telecom
>>>> 
>>>> [WAJ] This situation is for extraVPN communication, and should be designed carefully to avoid the address collision.. 
>>> Gyan Mishra
>>> Network Solutions Architect 
>>> M 301 502-1347
>>> 13101 Columbia Pike 
>>> Silver Spring, MD
>>> 
> -- 
> 
> 
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 6 Aug 2020 12:52:39 +0000

Comments In-Line

Jim Uttaro

From: Idr <[email-masked]> On Behalf Of Aijun Wang
Sent: Thursday, August 06, 2020 7:30 AM
To: Gyan Mishra <[email-masked]>
Cc: Keyur Patel <[email-masked]>; [email-masked]; Robert Raszuk <[email-masked]>; idr <[email-masked]>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Hi, Gyan and Robert:

Maximum Prefix Limit is one method to control the routes between PE and CE, but we should not depend only on it.
[Jim U>] Why? You can also simply send the default to the CE from the PE if a customer orders that feature?

Hi Robert

Kind Regards

Gyan

On Thu, Aug 6, 2020 at 5:49 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Thx,
R.

On Thu, Aug 6, 2020 at 11:41 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:
Hi Aijun

Kind Regards

Gyan

On Wed, Aug 5, 2020 at 12:49 PM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Robert:

Aijun Wang
China Telecom

On Aug 6, 2020, at 00:14, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Kind regards,
R.

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=vGUVGeSbIaab3CHZXYR9nTdhoC9n8mJmzBn-MXyjrhs&s=xe9tiWhsCBAU4lWYxLSLlSMM5biwWA8VyYSQkTsCKBY&e=>
--

[Image removed by sender.]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=vGUVGeSbIaab3CHZXYR9nTdhoC9n8mJmzBn-MXyjrhs&s=1CG15Fr_K45Y_dPT3zpGJPXt3MDr_d0XnL1mWRoWULg&e=>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-25C2-25A0-2BSilver-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=vGUVGeSbIaab3CHZXYR9nTdhoC9n8mJmzBn-MXyjrhs&s=utgIfn_Y9VMzfNxDpdsJaV6R1zVSL-Mtm6R24FmW1S4&e=>
Silver Spring, MD<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-25C2-25A0-2BSilver-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=vGUVGeSbIaab3CHZXYR9nTdhoC9n8mJmzBn-MXyjrhs&s=utgIfn_Y9VMzfNxDpdsJaV6R1zVSL-Mtm6R24FmW1S4&e=>

--

[Image removed by sender.]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=vGUVGeSbIaab3CHZXYR9nTdhoC9n8mJmzBn-MXyjrhs&s=1CG15Fr_K45Y_dPT3zpGJPXt3MDr_d0XnL1mWRoWULg&e=>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 6 Aug 2020 18:49:51 -0400

> CE, but we should not depend only on it.

   You can use maximum prefix along with an inbound filter prefix list or
as path or community match for whatever style routing control desired.

>From a PE standpoint you have not explained why using the per VRF prefix
limit to limit the size of the per VRF rib.  Please explain why that does
not solve the problem.

> RD-ORF can limit the influence scope of misbehavior PE as small as

    I don’t think you want to use RD-ORF as that would drop all routes from
a PE and RTC does the job well only advertising RTs imported on the PE.  I
think it would be rare if ever that anyone would ever filter on RD.

>
> RT-ORF can suppress the routes from unwanted VRFs, but can’t suppress the
> overflow routes in VRF that it is interested.
>

> [WAJ] Such situation can only happen at the extraVPN scenarios which
> should be designed carefully——one must keep the prefixes in these VRFs not
> overlap. But if the prefixes in these VRFs are not overlap, why do we need
> to separate them in different VRFs?
>>> As Robert mentioned each VRF has a maximum prefix which is defined on
>>> the PE RIBs per VRF and in general on most current or even hardware within
>>> the last 10 years is a minimum 1M prefixes per VRF is pretty standard with
>>> most vendors and platforms.  The vpn rib limit is much much higher on the
>>> higher end platforms.
>>>
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
> --

*Gyan Mishra*

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 7 Aug 2020 01:05:09 +0200

Folks,

I think we need to step back and first understand what is the problem.

Statements "overload of the PE" .. "overwhelmed PE" etc ... are really not
helpful. Neither are sufficient to justify this work based on the statement
"we need more then one solution" etc ....

What exactly is being considered a problem here ?

1. Running out of RAM in control plane ?
2. Running out of CPU in control plane ?
3. Not being able to import VPNv4 routes to a VRFs due to not enough
control plane memory ?
4. Not being able to import VPNv4 routes to a VRFs due to not enough data
plane memory ?

And please do not say "all of the above" as it will also not much
productive.

While stating the above please indicate which vendors have been tested and
do not meet feature wise sufficient protection.

Many thx,
R.

On Fri, Aug 7, 2020 at 12:50 AM Gyan Mishra <[email-masked]> wrote:

>     I don’t think you want to use RD-ORF as that would drop all routes
> from a PE and RTC does the job well only advertising RTs imported on the
> PE.  I think it would be rare if ever that anyone would ever filter on RD.
>
>>
>>>> You draft talks about inter-as issues solved with RT-ORF.  So when
>>>> PE-PE inter-as option B by default all RTs are dropped due to default RT

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 7 Aug 2020 08:58:47 +0800

Hi, Jim:

Please see the clarification inline below.

From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Thursday, August 6, 2020 8:53 PM
To: Aijun Wang <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: Keyur Patel <[email-masked]>; [email-masked]; Robert Raszuk <[email-masked]>; idr <[email-masked]>
Subject: RE: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Comments In-Line

Jim Uttaro

From: Idr <[email-masked] <mailto:[email-masked]> > On Behalf Of Aijun Wang
Sent: Thursday, August 06, 2020 7:30 AM
To: Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Cc: Keyur Patel <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Robert Raszuk <[email-masked] <mailto:[email-masked]> >; idr <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Hi, Gyan and Robert:

[WAJ] Sorry for the inaccurate description. What I want to say are the followings:

1)     Maximum Prefix Limit is one method to control the routes between PE and CE.

2)     But we should not depend only on it to make sure all PEs within the domain will be configured/behavior properly.

3)     In such cases, we should suppress/back pressure the overflowed VPN routes as soon as possible, keep the possible disaster in limited scope.

Aijun Wang

China Telecom

On Aug 6, 2020, at 18:02, Gyan Mishra <[email-masked] <mailto:[email-masked]> > wrote:

Hi Robert 

Kind Regards 

Gyan

On Thu, Aug 6, 2020 at 5:49 AM Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

Hi Gyan,

Thx,
R.

 

On Thu, Aug 6, 2020 at 11:41 AM Gyan Mishra <[email-masked] <mailto:[email-masked]> > wrote:

Hi Aijun

 

Kind Regards 

Gyan

On Wed, Aug 5, 2020 at 12:49 PM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

Aijun Wang

China Telecom

On Aug 6, 2020, at 00:14, Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

 

Kind regards,
R.

 

_______________________________________________
Idr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/idr <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=vGUVGeSbIaab3CHZXYR9nTdhoC9n8mJmzBn-MXyjrhs&s=xe9tiWhsCBAU4lWYxLSLlSMM5biwWA8VyYSQkTsCKBY&e=> 

-- 

 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=vGUVGeSbIaab3CHZXYR9nTdhoC9n8mJmzBn-MXyjrhs&s=1CG15Fr_K45Y_dPT3zpGJPXt3MDr_d0XnL1mWRoWULg&e=> 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-25C2-25A0-2BSilver-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=vGUVGeSbIaab3CHZXYR9nTdhoC9n8mJmzBn-MXyjrhs&s=utgIfn_Y9VMzfNxDpdsJaV6R1zVSL-Mtm6R24FmW1S4&e=>  
Silver Spring, MD <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-25C2-25A0-2BSilver-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=vGUVGeSbIaab3CHZXYR9nTdhoC9n8mJmzBn-MXyjrhs&s=utgIfn_Y9VMzfNxDpdsJaV6R1zVSL-Mtm6R24FmW1S4&e=> 

-- 

 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=vGUVGeSbIaab3CHZXYR9nTdhoC9n8mJmzBn-MXyjrhs&s=1CG15Fr_K45Y_dPT3zpGJPXt3MDr_d0XnL1mWRoWULg&e=> 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 7 Aug 2020 09:19:59 +0800

Hi, Robert and Gyan:

The problem is similar as that for “BGP Maximum-Prefix” and should be control plane related issue.

No matter what’s the capabilities of the router, there is always the roof for its performance.  

And in large network deployment, there still exist the possibility that one or some PEs are misconfigured/attacked etc.  

We should not only control the PE behavior at network edge(for example, using BGP Maximum-Prefix feature), but also need to consider the risk within the network.   

RTC is one kind of method to control the routes propagation within the network, but it is not enough. 

RTC can filter the VRF routes it doesn’t want to, but it can’t suppress the VPN routes it wants.  Using RD-ORF can control the VPN routes limits within each VRF. 

Best Regards

Aijun Wang

China Telecom

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Friday, August 7, 2020 7:05 AM
To: Aijun Wang <[email-masked]>; [email-masked]
Cc: Keyur Patel <[email-masked]>; idr <[email-masked]>; Gyan Mishra <[email-masked]>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Folks,

Statements "overload of the PE" .. "overwhelmed PE" etc ... are really not helpful. Neither are sufficient to justify this work based on the statement "we need more then one solution" etc .... 

3. Not being able to import VPNv4 routes to a VRFs due to not enough control plane memory ? 

4. Not being able to import VPNv4 routes to a VRFs due to not enough data plane memory ?   

And please do not say "all of the above" as it will also not much productive. 

While stating the above please indicate which vendors have been tested and do not meet feature wise sufficient protection. 

Many thx,

R.

On Fri, Aug 7, 2020 at 12:50 AM Gyan Mishra <[email-masked] <mailto:[email-masked]> > wrote:

On Thu, Aug 6, 2020 at 7:29 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Gyan and Robert:

   You can use maximum prefix along with an inbound filter prefix list or as path or community match for whatever style routing control desired.

>From a PE standpoint you have not explained why using the per VRF prefix limit to limit the size of the per VRF rib.  Please explain why that does not solve the problem.

    I don’t think you want to use RD-ORF as that would drop all routes from a PE and RTC does the job well only advertising RTs imported on the PE.  I think it would be rare if ever that anyone would ever filter on RD.

   

Aijun Wang

China Telecom

 

Hi Robert 

Kind Regards 

Gyan

Hi Gyan,

 

Thx,
R.

 

Hi Aijun

 

Kind Regards 

Gyan

Hi, Robert:

Aijun Wang

China Telecom

 

 

 

Kind regards,
R.

 

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>  
Silver Spring, MD <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g> 

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>  
Silver Spring, MD <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> 

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 7 Aug 2020 09:45:25 +0200

> Using RD-ORF can control the VPN routes limits within each VRF.

If you really want to create such inconsistency within any VPN you can ask
your vendor for a knob to locally drop on inbound received routes with
specific RD. That also can be fully automated by setting the auto trigger
threshold on a per VRF.

The inbound drop is a very low cost operation so will be of no CPU issue.

You will then be able to use such *local* knob as an additional safety
fuse.

There is however no need to propagate this anywhere nor to pass it from RR
to upstream PEs. Such knob can exist on RRs as well if you even further
want to completely break your user's happiness.

I see no need and I stay by original position that this proposed protocol
extension is a bad one and I do not support it to proceed any further nor
to be adopted as an IDR WG document.

Kind regards,

Robert

On Fri, Aug 7, 2020 at 3:20 AM Aijun Wang <[email-masked]> wrote:

> And in large network deployment, there still exist the possibility that
> one or some PEs are misconfigured/attacked etc.
>
> We should not only control the PE behavior at network edge(for example,
> using BGP Maximum-Prefix feature), but also need to consider the risk
> within the network.
>
>
>
> RTC can filter the VRF routes it doesn’t want to, but it can’t suppress
> the VPN routes it wants.  Using RD-ORF can control the VPN routes limits
> within each VRF.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *Sent:* Friday, August 7, 2020 7:05 AM
> *To:* Aijun Wang <[email-masked]>; [email-masked]
> *Cc:* Keyur Patel <[email-masked]>; idr <[email-masked]>; Gyan Mishra <
> [email-masked]>
> *Subject:* Re: [Idr] [Responses for the comments during the IETF108] New
> *Network Solutions Architect *
>
>
>
> *Network Solutions Architect *
>
>
>
> *Network Solutions Architect *
>
>
>

---

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

Hi, Robert:

According to your logic, what the reason for the ORF、RTC mechanism exist? The extra info that they filter can all be locally dropped.

Regarding the knob on RR, how RR know which routes it should drop by itself?

Back pressure to the source can eliminate the root of overflowed VPN routes.

Best Regards

Aijun Wang

China Telecom 

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Friday, August 7, 2020 3:45 PM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]; Keyur Patel <[email-masked]>; idr <[email-masked]>; Gyan Mishra <[email-masked]>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

 > Using RD-ORF can control the VPN routes limits within each VRF.

If you really want to create such inconsistency within any VPN you can ask your vendor for a knob to locally drop on inbound received routes with specific RD. That also can be fully automated by setting the auto trigger threshold on a per VRF. 

You will then be able to use such *local* knob as an additional safety fuse. 

There is however no need to propagate this anywhere nor to pass it from RR to upstream PEs. Such knob can exist on RRs as well if you even further want to completely break your user's happiness. 

I see no need and I stay by original position that this proposed protocol extension is a bad one and I do not support it to proceed any further nor to be adopted as an IDR WG document. 

Kind regards,

Robert

On Fri, Aug 7, 2020 at 3:20 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert and Gyan:

 

Best Regards

Aijun Wang

China Telecom

From: Robert Raszuk [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, August 7, 2020 7:05 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Cc: Keyur Patel <[email-masked] <mailto:[email-masked]> >; idr <[email-masked] <mailto:[email-masked]> >; Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Folks,

Many thx,

R.

 

Hi, Gyan and Robert:

   

Aijun Wang

China Telecom

 

Hi Robert 

Kind Regards 

Gyan

Hi Gyan,

Thx,
R.

 

Hi Aijun

 

Kind Regards 

Gyan

Hi, Robert:

Aijun Wang

China Telecom

 

 

Kind regards,
R.

 

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 7 Aug 2020 10:38:48 +0200

Hi Aijun,

The reason for RTC is to propagate information which routes are needed -
between PE & RR or between domains. The goal is to even further scale the
VPN route distribution.

RTC is not defined to signal which routes should be dropped due to low
resources. Very fundamental difference.

Prefix ORF in general is very rarely used. Reason being that it is normally
only applicable for eBGP sessions and no peer wants to honor someone
else's filters. For IBGP prefix ORF IMO should be forbidden by the spec.

Knob on RRs can be very simple: drop or stop propagating to any PE VPNv4 or
v6 routes if number of routes with given RD exceeds say 1 million or X.

And such 1 million or 1K or xyz can be based on expected number of VPN
routes from any L3VPN customer in his VPN. I do hope when customers sign
the agreement you ask that question.

> Back pressure to the source can eliminate the root of overflowed VPN
routes.

The problem is that you are not defining back pressure to the source. You
are defining back pressure to your own devices. If you were to define a
message which would tell the originator of the routes (customer CE) to stop
or which would bring down the session to the CE which is polluting the VPN
space I would perhaps carefully review it and maybe even support it.

But you are proposing a tool which just breaks VPNs without signalling it
to customers. That is not acceptable - very sorry.

Many thx,
R.

On Fri, Aug 7, 2020 at 10:20 AM Aijun Wang <[email-masked]>
wrote:

> Hi, Robert:
>
> According to your logic, what the reason for the ORF、RTC mechanism exist?
> The extra info that they filter can all be locally dropped.
>
> *Sent:* Friday, August 7, 2020 3:45 PM
> *Cc:* [email-masked]; Keyur Patel <[email-masked]>; idr <
> [email-masked]>; Gyan Mishra <[email-masked]>
> should be designed carefully——one must keep the prefixes in these VRFs
> not overlap. But if the prefixes in these VRFs are not overlap, why do we
> need to separate them in different VRFs?
>

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 7 Aug 2020 16:53:09 +0800

Hi, Robert:

The updated encoding of RD-ORF message includes the originator of routes (source PE).

Once the “source PE” receives such message, it can log this event, or notify the customer further via traditional “BGP Prefix Limit” mechanism.

If necessary, we can add such consideration later in the draft.

Best Regards

Aijun Wang

China Telecom

Sent: Friday, August 7, 2020 4:39 PM

Hi Aijun,

The reason for RTC is to propagate information which routes are needed - between PE & RR or between domains. The goal is to even further scale the VPN route distribution. 

RTC is not defined to signal which routes should be dropped due to low resources. Very fundamental difference. 

Prefix ORF in general is very rarely used. Reason being that it is normally only applicable for eBGP sessions and no peer wants to honor someone else's filters. For IBGP prefix ORF IMO should be forbidden by the spec. 

Knob on RRs can be very simple: drop or stop propagating to any PE VPNv4 or v6 routes if number of routes with given RD exceeds say 1 million or X. 

And such 1 million or 1K or xyz can be based on expected number of VPN routes from any L3VPN customer in his VPN. I do hope when customers sign the agreement you ask that question. 

> Back pressure to the source can eliminate the root of overflowed VPN routes.  

The problem is that you are not defining back pressure to the source. You are defining back pressure to your own devices. If you were to define a message which would tell the originator of the routes (customer CE) to stop or which would bring down the session to the CE which is polluting the VPN space I would perhaps carefully review it and maybe even support it. 

But you are proposing a tool which just breaks VPNs without signalling it to customers. That is not acceptable - very sorry. 

Many thx,
R.

On Fri, Aug 7, 2020 at 10:20 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom 

From: Robert Raszuk [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, August 7, 2020 3:45 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Keyur Patel <[email-masked] <mailto:[email-masked]> >; idr <[email-masked] <mailto:[email-masked]> >; Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Kind regards,

Robert

Hi, Robert and Gyan:

 

Best Regards

Aijun Wang

China Telecom

Folks,

Many thx,

R.

 

Hi, Gyan and Robert:

   

Aijun Wang

China Telecom

 

Hi Robert 

Kind Regards 

Gyan

Hi Gyan,

Thx,
R.

 

Hi Aijun

 

Kind Regards 

Gyan

Hi, Robert:

Aijun Wang

China Telecom

 

 

Kind regards,
R.

 

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 7 Aug 2020 13:50:43 +0200

ORF messages are p2p. They are not transitive.

There is no such thing like smuggling messages around even if they are
re-originated on RRs.

Thx,
R.

On Fri, Aug 7, 2020 at 10:53 AM Aijun Wang <[email-masked]>
wrote:

> Once the “source PE” receives such message, it can log this event, or
> notify the customer further via traditional “BGP Prefix Limit” mechanism.
>
> *Sent:* Friday, August 7, 2020 4:39 PM
> Prefix ORF in general is very rarely used. Reason being that it is
> normally only applicable for eBGP sessions and no peer wants to honor
> someone else's filters. For IBGP prefix ORF IMO should be forbidden by the
> spec.
>
>
>
> Knob on RRs can be very simple: drop or stop propagating to any PE VPNv4
> or v6 routes if number of routes with given RD exceeds say 1 million or X.
>
>
>

---

From: John E Drake <[email-masked]>
Date: Fri, 7 Aug 2020 12:34:50 +0000

Hi,

I agree with Robert’s analysis.  There is no need to define an external mechanism to deal with an internal node issue.

Yours Irrespectively,

John

Juniper Business Use Only
From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Friday, August 7, 2020 3:45 AM
To: Aijun Wang <[email-masked]>
Cc: Keyur Patel <[email-masked]>; [email-masked]; idr <[email-masked]>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

[External Email. Be cautious of content]

Kind regards,
Robert

On Fri, Aug 7, 2020 at 3:20 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Robert and Gyan:

Best Regards

Aijun Wang
China Telecom

From: Robert Raszuk [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 7, 2020 7:05 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Keyur Patel <[email-masked]<mailto:[email-masked]>>; idr <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Folks,

Many thx,
R.

On Fri, Aug 7, 2020 at 12:50 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Aug 6, 2020 at 7:29 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Gyan and Robert:

On Aug 6, 2020, at 18:02, Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Hi Robert

Kind Regards

Gyan

Thx,
R.

Kind Regards

Gyan

Aijun Wang
China Telecom

Kind regards,
R.

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-a4DS9kU$>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4CH5VmU$>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-TvDTsPA$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-TvDTsPA$>

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4CH5VmU$>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike*Silver*Spring,*MD?entry=gmail&source=g__;KysrKys!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4bIdg-w$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike*Silver*Spring,*MD?entry=gmail&source=g__;KysrKys!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4bIdg-w$>

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4CH5VmU$>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 7 Aug 2020 17:31:45 -0400

Hi Authors

I agree with Roberts’s analysis as well.

As pointed out by Robert this feature appears to be a dangerous addition to
the BGP specification.  The concept or idea of wanting to drop routes for
select devices based on criteria that is not holistic.

BGP is a holistic routing protocol and by that I mean consistent and
ubiquitous propagation of NLRI’s throughout the domain.  The concept of
resource constrained nodes and creating a BGP knob for resource constrained
nodes is out of the scope of the BGP protocol.  The goal and primary
purpose of BGP is to provide “reachability” a by that I mean every router
in the domain has a consistent view of the topology soft state and
identical RIB.  This is not different then the goal of an IGP to provide
next hop reachability and a consistent view of the domain meaning IGP
database synchronization.  Vendors provide plenty of knobs to filer that
consistent view of the domain but those are very one off exception use
cases where that happens in both the IGP and EGP world.  In the IGP world
for example take OSPF or ISIS you can as a corner case filter the IGP RIB
that is on a router with an inbound prefix filter.  This is an exception to
the rule but it must be done carefully as since the LSDB is “synchronized”
every router interface on every device in the domain bust now require that
same filter implemented as the database is “synchronized” for the goal of
both IGP and EGP to provide a consistent identical view of the domain.
Similarly with EGP such as BGP iBGP intra domain filtering is not
recommended and is not built by design to so as the goal BGO is to provide
the same reachability.  You can match and manipulate BGP attributes but not
filter as it will break the goal and primary purpose of BGP in the intra
domain construct of a consistent identical view throughout the domain.

There is already control mechanisms built into BGP to prevent routing loops
and re-advertisements such as BGP originator-id and cluster-id and cluster
list path created for route-reflector-client originated routes to prevent
loops as well as RR side sidenon client to non client re-advertisement
controls.

>From an IP VPN framework perspective you have to understand that a PE has
RT filtering enabled by default which is the control mechanism.  Their is
absolutely no need for any additional resource constrained node knob to
drop NLRI in what seems to be a random inconsistent fashion.  What PE “RT
filtering” means and this is a very basic concept but and applied directly
to what you are proposing and is the grounds to stop development of the
draft.  So when an RR advertises prefixes to a PE and let’s say their are a
million RTs and let’s say the PE is configured to import RT=1 and so only
one RT.  So now what happens is the RR advertises 1M RTs and the PE per “RT
filtering” drops 999,999 RTs as the PE only has RT=1 defined.

This issue caused unnecessary flood of RTs that soaks up operators
bandwidth that is not necessary that are going to be dropped anyway.

RTC to the rescue!!

RTC provides a elegant function to control advertisements from RR to PE and
is very robust and sensible in that it not dropping routes randomly or
because a few nodes have a resource constraint.  RTC has a well defined
purpose which is to cut down on a flood or RTs to a PE as described.

So the PE-RR peering had a RTC BGP MP reach AFI/SAFI defined on each peer
SAFI 132 enabled on each PE-RR peering  capability is established
send/receive state.  So now what happens is the PE does an ORF to the RR
stating that I only have RT=1 defined for import which is sent in a RTC
membership report to the RR.  The RR with RTC capability enabled now honors
what the PE has stated and only sends RT=1 and not 1M RTs.

Hooray for RTC saves the day = Job well done

This issue can be exacerbated with NNI inter-as when using option-b where
all VPN routes are propagated.  In this case we have default “RT filtering”
to the rescue to slow down the RT propagation to be done in a controlled
fashion.  So by default on the RR node does not have RT filtering enabled
by default and only PEs have that feature enabled by default. With Option-B
the inter-as link is PE-PE peering connecting the two SP domains together.
So looking deeper into option-b you can set “retain-route-target” which now
changes the default behavior and is required for the VPN routes to be
propagated.  In some cases between providers the RT does not match so a
RT-rewrite is required so in that case the rewrite policy become the RTC
like filtering mechanism.  In case where RT is the same between providers
we tie the “retain-route-target all” to a RT filter “RTC like” to only
accept RTs pertinent to the domain.

With inter-as option C we run BGP LU for labels unicast end loopback FEC
all leaked between domains via eBGP and IBGP LU for data plane forwarding
and the control plane function vpn peer that was on the PE-PE in option-b
is RR-RR eBGP vpnv4 vpnv6 SAFI 128.  Since the RR sits in the control plane
not the data plane “RT filtering” is not enabled by Default.  So for the
proper end to e f LSP data plane forwarding we have to set BGP
“next-hop-unchanged” so that the next hop attribute is now the ingress and
egress PEs between domains for the end to end LSP.  So now in this case all
the SAFI 128 RTs are propagated between domains.  You can apply explicit RT
filtering in this scenario but generally that is not done as opt-c used
mostly within same administrative domain or special agreement scenario
between SPs that work closely together or in M&A activity type scenarios.
So now we still have RTC SAFI 132 eatabled PE-RR within each domain so even
if you got a quadrillion RTs on the RR-RR peering and did not want to
filter there we have RTC back to the rescue and if you only have 1M RTs
defined for import on the PE within each domain,  now in a graceful
controlled fashion only 1M RTs are not advertised RR to PE within each
domain.

This same concept as IP VPN is an “overlay” it applies to SR both SR-MPLS
and SRv6 as well.

>From an BGP architecture and designer perspective when building a “SP core”
in that standard framework where you have separation of control plane and
data plane where the RRs are dedicated control plane function and don’t sit
in the data plane where the PEs RRC clients sit at the edge sit in the data
plane for ingress to egress LSP to FEC to be built.

So in a nutshell, a combination of default RT filtering on PEs, and
controlled RT advertisements via ORF RT membership via RTC we have complete
control of SAFI 128 advertisements for resource constrained nodes as it
stands today and there is absolutely no need for this draft to be
considered with IDR.

I did not mention the per VRF maximum prefix knobs to control how big each
VPN gets at a micro level so we have that control mechanism as well.  In
general most providers have this set as a rule of thumb per VRF maximum
which is sized accordingly to the lowest resource constrained node within
an operators network and is publish as the SLA customer agreement contract
as part of the VPN service offering.

Kind Regards

Gyan

On Fri, Aug 7, 2020 at 8:35 AM John E Drake <jdrake=
[email-masked]> wrote:

> Hi,
>
>
>
> I agree with Robert’s analysis.  There is no need to define an external
> mechanism to deal with an internal node issue.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Friday, August 7, 2020 3:45 AM
> *Cc:* Keyur Patel <[email-masked]>; [email-masked]; idr <
> [email-masked]>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-a4DS9kU$>
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4CH5VmU$>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>
> *Gyan Mishra*
>
> *M 301 502-1347 13101 Columbia Pike
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-TvDTsPA$>
> *Silver Spring, MD
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-TvDTsPA$>
>
>
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4CH5VmU$>
>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>*Gyan
> Mishra*
>
> *M 301 502-1347 13101 Columbia Pike
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike*Silver*Spring,*MD?entry=gmail&source=g__;KysrKys!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4bIdg-w$>
> *Silver Spring, MD
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike*Silver*Spring,*MD?entry=gmail&source=g__;KysrKys!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4bIdg-w$>
>
>
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4CH5VmU$>
>
> *Gyan Mishra*
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

*Gyan Mishra*

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 7 Aug 2020 22:21:03 +0000

The rationale for RTC is not to prevent paths being sent from an RR to a PE in a L3VPN. Granted that this could be a secondary benefit when routes are flooded from an RR towards a PE. Flooding of routes occurs in two cases:

  1.  PE is rebooting. In this case the PE is not operational so in reality it does not matter how many paths are being sent. I have seen millions of paths  being sent to a vintage router @1999 and it rips through these paths keeping the ones it needs for the VPNs instantiated on it and discarding the rest.  Again the PE is not up so it really does not matter.
  2.  A VRF is added to an existing PE that is operational. In this case the RR floods the paths towards the PE, the RE processes and keeps paths of interest. This processing in no way affects the forwarding aspect of the router. I have seen millions of paths flooded towards for this case and there is no effect on forwarding.

RTC’s assumption is that the RR topology services a set of VPNs that are localized. As an example, if VPN A is localized to California and VPN B to New York an RR topology that has two clusters East and West can deploy RTC to ensure the East cluster never has to “see” the VPN B routes and the West cluster never has to “see” the VPN A routes.

Generally speaking VPNs are not localized in this fashion and RTC has limited value and the downside of path hiding. Assume one wants to dual purpose the RR as a stitcher and wants to “stitch” as subset of VPN A paths to VPN B and vice versa.. Path hiding would prevent this.

Where RTC makes a lot of sense to me is where the VPN is local.. Specifically Kompella VPWS spec is by definition local where each VPN has two members in a point to point topology and is also generally localized to a given region/metro/LATA.  Here RTC can reduce the number of paths on RRs in a substantial manner. In the above ex all California VPWS paths are local and there is no need to populate said paths on the East coast RRs. This also makes sense for Kompella/VPLS, EVPN/VPLS, EVPN/VPWS, and EVPN/FXC..

Thanks,
              Jim Uttaro

From: Idr <[email-masked]> On Behalf Of Gyan Mishra
Sent: Friday, August 07, 2020 5:32 PM
To: John E Drake <jdrake=[email-masked]>
Cc: Keyur Patel <[email-masked]>; [email-masked]; Robert Raszuk <[email-masked]>; idr <[email-masked]>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Hi Authors

As pointed out by Robert this feature appears to be a dangerous addition to the BGP specification.  The concept or idea of wanting to drop routes for select devices based on criteria that is not holistic.

BGP is a holistic routing protocol and by that I mean consistent and ubiquitous propagation of NLRI’s throughout the domain.  The concept of resource constrained nodes and creating a BGP knob for resource constrained nodes is out of the scope of the BGP protocol.  The goal and primary purpose of BGP is to provide “reachability” a by that I mean every router in the domain has a consistent view of the topology soft state and identical RIB.  This is not different then the goal of an IGP to provide next hop reachability and a consistent view of the domain meaning IGP database synchronization.  Vendors provide plenty of knobs to filer that consistent view of the domain but those are very one off exception use cases where that happens in both the IGP and EGP world.  In the IGP world for example take OSPF or ISIS you can as a corner case filter the IGP RIB that is on a router with an inbound prefix filter.  This is an exception to the rule but it must be done carefully as since the LSDB is “synchronized” every router interface on every device in the domain bust now require that same filter implemented as the database is “synchronized” for the goal of both IGP and EGP to provide a consistent identical view of the domain.  Similarly with EGP such as BGP iBGP intra domain filtering is not recommended and is not built by design to so as the goal BGO is to provide the same reachability.  You can match and manipulate BGP attributes but not filter as it will break the goal and primary purpose of BGP in the intra domain construct of a consistent identical view throughout the domain.

There is already control mechanisms built into BGP to prevent routing loops and re-advertisements such as BGP originator-id and cluster-id and cluster list path created for route-reflector-client originated routes to prevent loops as well as RR side sidenon client to non client re-advertisement controls.

From an IP VPN framework perspective you have to understand that a PE has RT filtering enabled by default which is the control mechanism.  Their is absolutely no need for any additional resource constrained node knob to drop NLRI in what seems to be a random inconsistent fashion.  What PE “RT filtering” means and this is a very basic concept but and applied directly to what you are proposing and is the grounds to stop development of the draft.  So when an RR advertises prefixes to a PE and let’s say their are a million RTs and let’s say the PE is configured to import RT=1 and so only one RT.  So now what happens is the RR advertises 1M RTs and the PE per “RT filtering” drops 999,999 RTs as the PE only has RT=1 defined.

This issue caused unnecessary flood of RTs that soaks up operators bandwidth that is not necessary that are going to be dropped anyway.

RTC to the rescue!!

RTC provides a elegant function to control advertisements from RR to PE and is very robust and sensible in that it not dropping routes randomly or because a few nodes have a resource constraint.  RTC has a well defined purpose which is to cut down on a flood or RTs to a PE as described.

So the PE-RR peering had a RTC BGP MP reach AFI/SAFI defined on each peer SAFI 132 enabled on each PE-RR peering  capability is established send/receive state.  So now what happens is the PE does an ORF to the RR stating that I only have RT=1 defined for import which is sent in a RTC membership report to the RR.  The RR with RTC capability enabled now honors what the PE has stated and only sends RT=1 and not 1M RTs.

This issue can be exacerbated with NNI inter-as when using option-b where all VPN routes are propagated.  In this case we have default “RT filtering” to the rescue to slow down the RT propagation to be done in a controlled fashion.  So by default on the RR node does not have RT filtering enabled by default and only PEs have that feature enabled by default. With Option-B the inter-as link is PE-PE peering connecting the two SP domains together.  So looking deeper into option-b you can set “retain-route-target” which now changes the default behavior and is required for the VPN routes to be propagated.  In some cases between providers the RT does not match so a RT-rewrite is required so in that case the rewrite policy become the RTC like filtering mechanism.  In case where RT is the same between providers we tie the “retain-route-target all” to a RT filter “RTC like” to only accept RTs pertinent to the domain.

With inter-as option C we run BGP LU for labels unicast end loopback FEC all leaked between domains via eBGP and IBGP LU for data plane forwarding and the control plane function vpn peer that was on the PE-PE in option-b is RR-RR eBGP vpnv4 vpnv6 SAFI 128.  Since the RR sits in the control plane not the data plane “RT filtering” is not enabled by Default.  So for the proper end to e f LSP data plane forwarding we have to set BGP “next-hop-unchanged” so that the next hop attribute is now the ingress and egress PEs between domains for the end to end LSP.  So now in this case all the SAFI 128 RTs are propagated between domains.  You can apply explicit RT filtering in this scenario but generally that is not done as opt-c used mostly within same administrative domain or special agreement scenario between SPs that work closely together or in M&A activity type scenarios..  So now we still have RTC SAFI 132 eatabled PE-RR within each domain so even if you got a quadrillion RTs on the RR-RR peering and did not want to filter there we have RTC back to the rescue and if you only have 1M RTs defined for import on the PE within each domain,  now in a graceful controlled fashion only 1M RTs are not advertised RR to PE within each domain.

This same concept as IP VPN is an “overlay” it applies to SR both SR-MPLS and SRv6 as well.

From an BGP architecture and designer perspective when building a “SP core” in that standard framework where you have separation of control plane and data plane where the RRs are dedicated control plane function and don’t sit in the data plane where the PEs RRC clients sit at the edge sit in the data plane for ingress to egress LSP to FEC to be built.

So in a nutshell, a combination of default RT filtering on PEs, and controlled RT advertisements via ORF RT membership via RTC we have complete control of SAFI 128 advertisements for resource constrained nodes as it stands today and there is absolutely no need for this draft to be considered with IDR.

I did not mention the per VRF maximum prefix knobs to control how big each VPN gets at a micro level so we have that control mechanism as well.  In general most providers have this set as a rule of thumb per VRF maximum which is sized accordingly to the lowest resource constrained node within an operators network and is publish as the SLA customer agreement contract as part of the VPN service offering.

Kind Regards

Gyan

On Fri, Aug 7, 2020 at 8:35 AM John E Drake <jdrake=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Yours Irrespectively,

John

Juniper Business Use Only
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Friday, August 7, 2020 3:45 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Keyur Patel <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; idr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Kind regards,
Robert

On Fri, Aug 7, 2020 at 3:20 AM Aijun Wang <wangaijun@tsinghua..org.cn<mailto:[email-masked]>> wrote:
Hi, Robert and Gyan:

Best Regards

Aijun Wang
China Telecom

Folks,

I think we need to step back and first understand what is the problem..

Many thx,
R.

Hi Robert

Kind Regards

Gyan

Thx,
R.

Kind Regards

Gyan

Aijun Wang
China Telecom

Kind regards,
R.

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4CH5VmU$>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4CH5VmU$>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4CH5VmU$>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-2B-250D-250A-2BSilver-250D-250A-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=kb8pVf8ntO6E4jG6pvlsBLmUtavilrpnX2PILaFc_vA&e=>
Silver Spring, MD<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-2B-250D-250A-2BSilver-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=UQE3BUJasr5ZcHEdH-0LzGIJwz3iy0KbSLMIv56tJpc&e=>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=mTs47maTlB8UO2msI7upczQRr2XzfZo6WH0oHGTjek8&e=>
--

[Image removed by sender.]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=azo7pZGlG74ulHns4COMtA5JfBj1b5eA-HcHB74rYNw&e=>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 7 Aug 2020 18:39:20 -0400

Agreed and good points.

As you said the processing is not impacting the forwarding aspect.  Agreed.

As RTC is SAFI 132 flood control mechanism RR to PE optimization if you
have a ton of SAFI stacked as you’ve mentioned the optimization applies to
all the SAFI stacked onto the PE to RR peering.

RTC is an optimization in that respect and not a requirement as default RT
filtering rule application eliminates all accept what is explicitly
imported.

I gave the IP VPN example but as you stated the RTC optimization can be
used for a variety of SAFI but is not a requirement.

L3 VPN is a good example although it it does not really come into play as
much for intra domain as in general all PEs have the same VPNs defined,
however inter-as is a different story and there as that is not the case the
flooding can really be cut down as stated to interesting RTs only.

Thanks

Gyan

On Fri, Aug 7, 2020 at 6:21 PM UTTARO, JAMES <[email-masked]> wrote:

> *The rationale for RTC is not to prevent paths being sent from an RR to a
> PE in a L3VPN. Granted that this could be a secondary benefit when routes
> are flooded from an RR towards a PE. Flooding of routes occurs in two
> cases:*
>
>
>
>    1. *PE is rebooting. In this case the PE is not operational so in
>    reality it does not matter how many paths are being sent. I have seen
>    millions of paths  being sent to a vintage router @1999 and it rips through
>    these paths keeping the ones it needs for the VPNs instantiated on it and
>    discarding the rest.  Again the PE is not up so it really does not matter.*
>    2. *A VRF is added to an existing PE that is operational. In this case
>    the RR floods the paths towards the PE, the RE processes and keeps paths of
>    interest. This processing in no way affects the forwarding aspect of the
>    router. I have seen millions of paths flooded towards for this case and
>    there is no effect on forwarding.*
>
>
>
> *RTC’s assumption is that the RR topology services a set of VPNs that are
> localized. As an example, if VPN A is localized to California and VPN B to
> New York an RR topology that has two clusters East and West can deploy RTC
> to ensure the East cluster never has to “see” the VPN B routes and the West
> cluster never has to “see” the VPN A routes. *
>
>
>
> *Generally speaking VPNs are not localized in this fashion and RTC has
> limited value and the downside of path hiding. Assume one wants to dual
> purpose the RR as a stitcher and wants to “stitch” as subset of VPN A paths
> to VPN B and vice versa.. Path hiding would prevent this.*
>
>
>
> *Where RTC makes a lot of sense to me is where the VPN is local..
> Specifically Kompella VPWS spec is by definition local where each VPN has
> two members in a point to point topology and is also generally localized to
> a given region/metro/LATA.  Here RTC can reduce the number of paths on RRs
> in a substantial manner. In the above ex all California VPWS paths are
> local and there is no need to populate said paths on the East coast RRs.
> This also makes sense for Kompella/VPLS, EVPN/VPLS, EVPN/VPWS, and
> EVPN/FXC..*
>
>
>
> *Thanks,*
>
> *              Jim Uttaro*
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of * Gyan Mishra
> *Sent:* Friday, August 07, 2020 5:32 PM
> *To:* John E Drake <jdrake=[email-masked]>
> *Cc:* Keyur Patel <[email-masked]>; [email-masked]; Robert
> Raszuk <[email-masked]>; idr <[email-masked]>
> As pointed out by Robert this feature appears to be a dangerous addition
> to the BGP specification.  The concept or idea of wanting to drop routes
> for select devices based on criteria that is not holistic.
>
>
>
> There is already control mechanisms built into BGP to prevent routing
> loops and re-advertisements such as BGP originator-id and cluster-id and
> cluster list path created for route-reflector-client originated routes to
> prevent loops as well as RR side sidenon client to non client
> re-advertisement controls.
>
>
>
>
>
> RTC provides a elegant function to control advertisements from RR to PE
> and is very robust and sensible in that it not dropping routes randomly or
> between SPs that work closely together or in M&A activity type scenarios..
> From an BGP architecture and designer perspective when building a “SP
> core” in that standard framework where you have separation of control plane
> and data plane where the RRs are dedicated control plane function and don’t
> sit in the data plane where the PEs RRC clients sit at the edge sit in the
> data plane for ingress to egress LSP to FEC to be built.
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk
> On Fri, Aug 7, 2020 at 3:20 AM Aijun Wang <wangaijun@tsinghua..org.cn
> <[email-masked]>> wrote:
>
> Hi, Robert and Gyan:
>
>
>
> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>*Network
> Solutions Architect *
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-2B-250D-250A-2BSilver-250D-250A-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=kb8pVf8ntO6E4jG6pvlsBLmUtavilrpnX2PILaFc_vA&e=>
> *Silver Spring, MD
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-2B-250D-250A-2BSilver-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=UQE3BUJasr5ZcHEdH-0LzGIJwz3iy0KbSLMIv56tJpc&e=>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=mTs47maTlB8UO2msI7upczQRr2XzfZo6WH0oHGTjek8&e=>
>
> --
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=azo7pZGlG74ulHns4COMtA5JfBj1b5eA-HcHB74rYNw&e=>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 10 Aug 2020 09:58:49 +0800

Hi, Gyan, Jim, John and Robert:

Thanks for your detail analysis. 

Actually, we know the value of RTC mechanism, but it is not enough for controlling the route limit within one VRF.

The propagation of routes that influence the router performance can come from different VRFs and can also come from the same VRF.

RTC aims to solve the former problem, RD-ORF aims to solve the latter.

If we depend on the local discard, as Robert proposed, the route inconsistence can also occur. It is the sacrifice we should accept. 

Using the RD-ORF can restrict the influence within one limited scope(within one VRF, one PE, one domain or different domains), in controlled manner.

RD-ORF is based on the ORF mechanism, which is transferred via P2P message. Every node on the path can have its policy to determine whether or not sending this filter information to the upstream BGP peer, based on its performance criteria. 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Saturday, August 8, 2020 6:39 AM
To: UTTARO, JAMES <[email-masked]>
Cc: Keyur Patel <[email-masked]>; John E Drake <jdrake=[email-masked]>; [email-masked]; Robert Raszuk <[email-masked]>; idr <[email-masked]>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Agreed and good points.

As RTC is SAFI 132 flood control mechanism RR to PE optimization if you have a ton of SAFI stacked as you’ve mentioned the optimization applies to all the SAFI stacked onto the PE to RR peering.

RTC is an optimization in that respect and not a requirement as default RT filtering rule application eliminates all accept what is explicitly imported.  

I gave the IP VPN example but as you stated the RTC optimization can be used for a variety of SAFI but is not a requirement.

L3 VPN is a good example although it it does not really come into play as much for intra domain as in general all PEs have the same VPNs defined, however inter-as is a different story and there as that is not the case the flooding can really be cut down as stated to interesting RTs only.

Thanks 

Gyan

On Fri, Aug 7, 2020 at 6:21 PM UTTARO, JAMES <[email-masked] <mailto:[email-masked]> > wrote:

a.  PE is rebooting. In this case the PE is not operational so in reality it does not matter how many paths are being sent. I have seen millions of paths  being sent to a vintage router @1999 and it rips through these paths keeping the ones it needs for the VPNs instantiated on it and discarding the rest.  Again the PE is not up so it really does not matter.

b.  A VRF is added to an existing PE that is operational. In this case the RR floods the paths towards the PE, the RE processes and keeps paths of interest. This processing in no way affects the forwarding aspect of the router. I have seen millions of paths flooded towards for this case and there is no effect on forwarding.

Thanks,

              Jim Uttaro

From: Idr <[email-masked] <mailto:[email-masked]> > On Behalf Of Gyan Mishra
Sent: Friday, August 07, 2020 5:32 PM
To: John E Drake <jdrake=[email-masked] <mailto:[email-masked]> >
Cc: Keyur Patel <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Robert Raszuk <[email-masked] <mailto:[email-masked]> >; idr <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Hi Authors 

BGP is a holistic routing protocol and by that I mean consistent and ubiquitous propagation of NLRI’s throughout the domain.  The concept of resource constrained nodes and creating a BGP knob for resource constrained nodes is out of the scope of the BGP protocol.  The goal and primary purpose of BGP is to provide “reachability” a by that I mean every router in the domain has a consistent view of the topology soft state and identical RIB..  This is not different then the goal of an IGP to provide next hop reachability and a consistent view of the domain meaning IGP database synchronization.  Vendors provide plenty of knobs to filer that consistent view of the domain but those are very one off exception use cases where that happens in both the IGP and EGP world.  In the IGP world for example take OSPF or ISIS you can as a corner case filter the IGP RIB that is on a router with an inbound prefix filter.  This is an exception to the rule but it must be done carefully as since the LSDB is “synchronized” every router interface on every device in the domain bust now require that same filter implemented as the database is “synchronized” for the goal of both IGP and EGP to provide a consistent identical view of the domain.  Similarly with EGP such as BGP iBGP intra domain filtering is not recommended and is not built by design to so as the goal BGO is to provide the same reachability.  You can match and manipulate BGP attributes but not filter as it will break the goal and primary purpose of BGP in the intra domain construct of a consistent identical view throughout the domain.

 

RTC to the rescue!! 

Kind Regards 

Gyan

On Fri, Aug 7, 2020 at 8:35 AM John E Drake <jdrake=[email-masked] <mailto:[email-masked]> > wrote:

Hi,

Yours Irrespectively,

John

From: Idr <[email-masked] <mailto:[email-masked]> > On Behalf Of Robert Raszuk
Sent: Friday, August 7, 2020 3:45 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Keyur Patel <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; idr <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

 

Kind regards,

Robert

On Fri, Aug 7, 2020 at 3:20 AM Aijun Wang <wangaijun@tsinghua...org.cn <mailto:[email-masked]> > wrote:

Hi, Robert and Gyan:

 

Best Regards

Aijun Wang

China Telecom

Folks,

Statements "overload of the PE" .. "overwhelmed PE" etc ... are really not helpful. Neither are sufficient to justify this work based on the statement "we need more then one solution" etc ..... 

Many thx,

R.

 

Hi, Gyan and Robert:

>From a PE standpoint you have not explained why using the per VRF prefix limit to limit the size of the per VRF rib.  Please explain why that does not solve the problem.

RD-ORF can limit the influence scope of misbehavior PE as small as possible..

   

Aijun Wang

China Telecom

 

Hi Robert 

Kind Regards 

Gyan

Hi Gyan,

Thx,
R.

 

Hi Aijun

 

Kind Regards 

Gyan

Hi, Robert:

Aijun Wang

China Telecom

On Aug 6, 2020, at 00:14, Robert Raszuk <[email-masked] <mailto:robert@raszuk..net> > wrote:

 

Kind regards,
R.

 

_______________________________________________
Idr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/idr <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-a4DS9kU$> 

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-TvDTsPA$>  
Silver Spring, MD <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-TvDTsPA$> 

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike*Silver*Spring,*MD?entry=gmail&source=g__;KysrKys!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4bIdg-w$>  
Silver Spring, MD <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike*Silver*Spring,*MD?entry=gmail&source=g__;KysrKys!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4bIdg-w$> 

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-2B-250D-250A-2BSilver-250D-250A-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=kb8pVf8ntO6E4jG6pvlsBLmUtavilrpnX2PILaFc_vA&e=>  
Silver Spring, MD <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-2B-250D-250A-2BSilver-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=UQE3BUJasr5ZcHEdH-0LzGIJwz3iy0KbSLMIv56tJpc&e=> 

_______________________________________________
Idr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/idr <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=mTs47maTlB8UO2msI7upczQRr2XzfZo6WH0oHGTjek8&e=> 

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>  
Silver Spring, MD <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> 

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 10 Aug 2020 11:05:32 +0200

Aijun,

> Using the RD-ORF can restrict the influence within one limited
scope(within one VRF, one PE, one domain or different domains)

Please kindly observed that this is still not enough of granularity.

As you know src VRF can have many CEs and perhaps just one of them say out
of 10 is injecting trashing routes. Then IMO penalizing reachability to all
10 CEs instead of 1 is a very bad thing to do to your customer's VPN.

RD is per VRF and not per CE and does not provide sufficient granularity to
address the protection problem you are pointing out.

Also apologies if I missed it but I do not think you have sufficiently
explained what is wrong with using the prefix limit on incoming sessions to
your PE. You said this is one way. If it solves the problem why to invent
different way ? If it does not solve the problem please explain why.

Thx,
R.

On Mon, Aug 10, 2020 at 3:58 AM Aijun Wang <[email-masked]>
wrote:

> Actually, we know the value of RTC mechanism, but it is not enough for
> controlling the route limit within one VRF.
>
> The propagation of routes that influence the router performance can come
> from different VRFs and can also come from the same VRF.
>
> If we depend on the local discard, as Robert proposed, the route
> inconsistence can also occur. It is the sacrifice we should accept.
>
> Using the RD-ORF can restrict the influence within one limited
> scope(within one VRF, one PE, one domain or different domains), in
> controlled manner.
>
> RD-ORF is based on the ORF mechanism, which is transferred via P2P
> message. Every node on the path can have its policy to determine whether or
> not sending this filter information to the upstream BGP peer, based on its
> performance criteria.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Gyan
> Mishra
> *Sent:* Saturday, August 8, 2020 6:39 AM
> *To:* UTTARO, JAMES <[email-masked]>
> *Cc:* Keyur Patel <[email-masked]>; John E Drake <jdrake=
> [email-masked]>; [email-masked]; Robert Raszuk <
> [email-masked]>; idr <[email-masked]>
> a.  *PE is rebooting. In this case the PE is not operational so in
> b.  *A VRF is added to an existing PE that is operational. In this case
> *From:* Idr <[email-masked]> *On Behalf Of *Gyan Mishra
> identical RIB..  This is not different then the goal of an IGP to provide
> On Fri, Aug 7, 2020 at 3:20 AM Aijun Wang <wangaijun@tsinghua...org.cn
> "we need more then one solution" etc .....
>
>
>
> On Aug 6, 2020, at 00:14, Robert Raszuk <[email-masked]
> <robert@raszuk..net>> wrote:
>
> 
>
>
>
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-TvDTsPA$>*Silver
> Spring, MD
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike*Silver*Spring,*MD?entry=gmail&source=g__;KysrKys!!NEt6yMaO-gk!SSHG20ZmwUSGrSuTtfa4JNe7b713829oIhwBxGXTcW3O1752RosOFtA-4bIdg-w$> *Silver
> Spring, MD
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_maps_search_13101-2BColumbia-2BPike-2B-250D-250A-2BSilver-250D-250A-2BSpring-2C-2BMD-3Fentry-3Dgmail-26source-3Dg&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=itVE7Lg-n8l1xT0dj7-RPre4YUXzly9oKLfj0FCmRtk&s=kb8pVf8ntO6E4jG6pvlsBLmUtavilrpnX2PILaFc_vA&e=> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 10 Aug 2020 17:20:02 +0800

Hi, Robert:

RD-ORF is mainly for restricting PE from sending trashing routes. When the source PE receives such notification info, it should find which CE is the real source of the routes. This is not the scope of this draft, but if necessary, we can add some deployment consideration for this part later.

“Prefix Limit” mechanism can only protect the edge between PE-CE, can’t be deployed within PE that peered via RR.  We should not rely solely on the edge protection.

You can also refer our discussion at https://mailarchive.ietf.org/arch/msg/idr/d79fKMXa3HZcq6Zti5H7qnxJ1_o/

Best Regards

Aijun Wang

China Telecom

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Monday, August 10, 2020 5:06 PM
To: Aijun Wang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; UTTARO, JAMES <[email-masked]>; Keyur Patel <[email-masked]>; John E Drake <jdrake=[email-masked]>; [email-masked]; idr <[email-masked]>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Aijun,

> Using the RD-ORF can restrict the influence within one limited scope(within one VRF, one PE, one domain or different domains)  

As you know src VRF can have many CEs and perhaps just one of them say out of 10 is injecting trashing routes. Then IMO penalizing reachability to all 10 CEs instead of 1 is a very bad thing to do to your customer's VPN. 

RD is per VRF and not per CE and does not provide sufficient granularity to address the protection problem you are pointing out. 

Also apologies if I missed it but I do not think you have sufficiently explained what is wrong with using the prefix limit on incoming sessions to your PE. You said this is one way. If it solves the problem why to invent different way ? If it does not solve the problem please explain why. 

Thx,
R.

On Mon, Aug 10, 2020 at 3:58 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Gyan Mishra
Sent: Saturday, August 8, 2020 6:39 AM
To: UTTARO, JAMES <[email-masked] <mailto:[email-masked]> >
Cc: Keyur Patel <[email-masked] <mailto:[email-masked]> >; John E Drake <jdrake=[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Robert Raszuk <[email-masked] <mailto:[email-masked]> >; idr <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Agreed and good points.

Thanks 

Gyan

Thanks,

              Jim Uttaro

Hi Authors 

 

RTC to the rescue!! 

Kind Regards 

Gyan

Hi,

Yours Irrespectively,

John

 

Kind regards,

Robert

Hi, Robert and Gyan:

 

Best Regards

Aijun Wang

China Telecom

Folks,

Many thx,

R.

 

Hi, Gyan and Robert:

   

Aijun Wang

China Telecom

 

Hi Robert 

Kind Regards 

Gyan

Hi Gyan,

Thx,
R.

 

Hi Aijun

 

Kind Regards 

Gyan

Hi, Robert:

Aijun Wang

China Telecom

 

 

Kind regards,
R.

 

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Gert Doering <[email-masked]>
Date: Mon, 10 Aug 2020 11:28:41 +0200

Hi,

On Mon, Aug 10, 2020 at 05:20:02PM +0800, Aijun Wang wrote:
> ???Prefix Limit??? mechanism can only protect the edge between PE-CE, can???t be deployed within PE that peered via RR.  We should not rely solely on the edge protection.

You must have proper edge protection in place.

If you do not have this, everything else is bandaid at best, and dangerous
at worst.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 11 Aug 2020 09:52:34 +0800

Hi, Gert:

What dangerous are you worrying then?
RD-ORF mechanism is enhancing the anti-attack capabilities of the network.
It enhances also the quick-reaction capability of network.   

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Monday, August 10, 2020 5:29 PM
To: Aijun Wang <[email-masked]>
Cc: 'Robert Raszuk' <[email-masked]>; 'idr' <[email-masked]>; 'Keyur Patel'
<[email-masked]>; 'John E Drake' <jdrake=[email-masked]>;
[email-masked]; 'UTTARO, JAMES' <[email-masked]>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New
Version Notification for draft-wang-idr-rd-orf-01.txt

Hi,

On Mon, Aug 10, 2020 at 05:20:02PM +0800, Aijun Wang wrote:
> ???Prefix Limit??? mechanism can only protect the edge between PE-CE,
can???t be deployed within PE that peered via RR.  We should not rely solely
on the edge protection.

Gert Doering
        -- NetMaster

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Tue, 11 Aug 2020 10:01:38 +0200

Hi

> It enhances also the quick-reaction capability of network.   

You have a working mechanism.

In the worry that this mechanism might not be properly configured, you
add lots of extra complexity to BGP, which will have to be implemented
and maintained by vendors.  Every new line of code has the risk of 
carrying bugs, so if it's not beneficial (because a working solution
exists) it should not be added.

Otherwise: what Robert says.

Gert Doering
        -- NetMaster

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 11 Aug 2020 15:53:38 -0400

Aijun

If you use maximum prefix on every PE-CE peering at the edge how would the
PE-RR peering send “trashing routes”.  The “trashing routes” would not be
present in the VPN RIB on the PE to send to the RR.

To me that’s “Problem Solved”.

Kind Regards

Gyan

On Mon, Aug 10, 2020 at 5:20 AM Aijun Wang <[email-masked]>
wrote:

> Hi, Robert:
>
>
>
> RD-ORF is mainly for restricting PE from sending trashing routes. When the
> source PE receives such notification info, it should find which CE is the
> real source of the routes. This is not the scope of this draft, but if
> necessary, we can add some deployment consideration for this part later.
>
> “Prefix Limit” mechanism can only protect the edge between PE-CE, can’t be
> deployed within PE that peered via RR.  We should not rely solely on the
> edge protection.
>
>
>
> You can also refer our discussion at
> https://mailarchive.ietf.org/arch/msg/idr/d79fKMXa3HZcq6Zti5H7qnxJ1_o/
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *Sent:* Monday, August 10, 2020 5:06 PM
> *Cc:* Gyan Mishra <[email-masked]>; UTTARO, JAMES <[email-masked]>;
> Keyur Patel <[email-masked]>; John E Drake <jdrake=
> [email-masked]>; [email-masked]; idr <[email-masked]>
> RD is per VRF and not per CE and does not provide sufficient
> granularity to address the protection problem you are pointing out.
>
>
>
> have a ton of SAFI stacked as you’ve mentioned the optimization applies
> to all the SAFI stacked onto the PE to RR peering.
>
>
>
> filtering” means and this is a very basic concept but and applied
> directly to what you are proposing and is the grounds to stop development
> of the draft.  So when an RR advertises prefixes to a PE and let’s say
> their are a million RTs and let’s say the PE is configured to import RT=1
> and so only one RT.  So now what happens is the RR advertises 1M RTs and
> the PE per “RT filtering” drops 999,999 RTs as the PE only has RT=1
> defined.
>
>
>
> all VPN routes are propagated.  In this case we have default “RT filtering
> ” to the rescue to slow down the RT propagation to be done in a
> controlled fashion.  So by default on the RR node does not have RT
> filtering enabled by default and only PEs have that feature enabled by
> default. With Option-B the inter-as link is PE-PE peering connecting the
> two SP domains together.  So looking deeper into option-b you can set “
> retain-route-target” which now changes the default behavior and is
> required for the VPN routes to be propagated.  In some cases between
> providers the RT does not match so a RT-rewrite is required so in that case
> the rewrite policy become the RTC like filtering mechanism.  In case where
> RT is the same between providers we tie the “retain-route-target all” to
> a RT filter “RTC like” to only accept RTs pertinent to the domain.
>
>
>
> proper end to e f LSP data plane forwarding we have to set BGP “
> next-hop-unchanged” so that the next hop attribute is now the ingress and
> From an BGP architecture and designer perspective when building a “SP core
> ” in that standard framework where you have separation of control plane
> are what is advertised by the RR.  That i
>
> --

*Gyan Mishra*

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 12 Aug 2020 09:41:57 +0800

Hi, Gyan:

Theoretically, you are right.

But, don’t’ you worry that if only one of the edge points being comprised/error-configured/attacked, then all of PEs within your domain are under risk? 

Furthermore, if you control different domains, and use Option-B/C to provide the inter-AS VPN services, such risk/”trashing routes” can easily spread among these domains?

Don’t’ you think such network is too fragile?

RD-ORF is the mechanism that aims to strengthen the risk resistance capabilities.

Best Regards

Aijun Wang

China Telecom

From: Gyan Mishra [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2020 3:54 AM
To: Aijun Wang <[email-masked]>
Cc: John E Drake <jdrake=[email-masked]>; Keyur Patel <[email-masked]>; Robert Raszuk <[email-masked]>; UTTARO, JAMES <[email-masked]>; idr <[email-masked]>; [email-masked]
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Aijun 

If you use maximum prefix on every PE-CE peering at the edge how would the PE-RR peering send “trashing routes”.  The “trashing routes” would not be present in the VPN RIB on the PE to send to the RR.  

Kind Regards 

Gyan

On Mon, Aug 10, 2020 at 5:20 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Cc: Gyan Mishra <[email-masked] <mailto:[email-masked]> >; UTTARO, JAMES <[email-masked] <mailto:[email-masked]> >; Keyur Patel <[email-masked] <mailto:[email-masked]> >; John E Drake <jdrake=[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; idr <[email-masked] <mailto:[email-masked]> >

Aijun,

Thx,
R.

Best Regards

Aijun Wang

China Telecom

Agreed and good points.

Thanks 

Gyan

Thanks,

              Jim Uttaro

Hi Authors 

 

RTC to the rescue!! 

Kind Regards 

Gyan

Hi,

Yours Irrespectively,

John

 

Kind regards,

Robert

Hi, Robert and Gyan:

 

Best Regards

Aijun Wang

China Telecom

Folks,

Many thx,

R.

 

Hi, Gyan and Robert:

   

Aijun Wang

China Telecom

 

Hi Robert 

Kind Regards 

Gyan

Hi Gyan,

Thx,
R.

 

Hi Aijun

 

I am not sure I understand what problem you are trying to solve that is not already solved by RTC membership so that only RTs imported by the PE are what is advertised by the RR.  That i

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 12 Aug 2020 02:01:56 -0400

Hi Aijun

Standard practice for service providers is to have Infrastructure ACLs I
call “Leaving the Kingdom” as when a packet enters or leaves the trusted SP
domain it is a requirement per security posture for providers to secure the
edge.  As far as config errors, centralized NMS controller for
Restconf/Yang southbound policy push is the standard practice and that
makes for ZTP and day to to day operations configuration changes error free.

As far as inter domain for opt B & C your control point is still your PE-CE
protecting your edges from a control plane perspective and data plane
perspective via infrastructure ACLs.  The NNI inter as link with option B
is already a built in control point by design as you have to turn on
retain-route-target all and then tie to a policy for interesting RTs to
import as well as if their is an RT mismatch you have to manually via the
same protection policy perform a RT-Rewrite.

For Option C the SAFI 128 VPN control plane Is RR-RR so no RT filtering by
default but not to worry as RTC takes care of the RR-PE advertisements.

I know your concern is with trashing of routes, however if you think about
it “who originates the trashing routes” ?

So in this particular case it would be the provider outside of your
administrative control.

If it’s the inter-as is within a single administrative domain that is one
thing but if it’s outside of the operators administrative domain and if
this issue exists with certain RTs they have trashing routes or RD.  I do
see your point with opt b and c.

In those cases where you had an RT or RD that had trashing routes you could
switch those to option-a back to back VRF and apply the maximum prefix
filter.

So I think we have narrowed the scope of the trashing routes to inter-as
opt b or c going between administrative domains.  At that layer you cannot
does the maxim prefix knob as it’s a VPN peer carrying all RTs.  So all you
can do is filter on RTs.

I do still stand by the per VRF maximum prefix knob as the first global
control point that would be set on all PEs including the NNI inter-as
boundary PEs and that would be your first line of defense against trashing
routes.

An example of how that would work is if you set the per VRF maximum to
100,000 prefixes.  Let’s say you get 1M+ prefixes on a 1000 different VRFs
and that happened all simultaneously a coincidental flood with all the
stars and moons in alignment.

 In that case for each VRF you would drop 900,000 routers per VPN.

The RD-ORF or RT-ORF is still working at the RD RT VPN layer and does not
have the prefix level granularity as the PE-CE maximum prefix.

On every inter-as b c NNI if their was an RT that is thrashing you could
adjust the RT filter / RT translation policy to not permit the RT doing the
thrashing.

As far as the RD-ORF the RD is used to make the prefix unique 64 bit
quantity so you can have overlapping prefixes within different VRFs unique
by the RD.  As far as filtering their is no need to ever filter using RD.
That is never done in practice that I know of.  So I would remove that from
the draft.  The RD is usually set to auto which makes it unique within a
domain and of using a RR is required to be set to auto so that all the RDs
originated by each PE has a different RD so that they all get reflected by
the RR.  Without that sub optimal routing can occur as all paths are not
reflected.  In that the case of RD auto making the RD unique per VRF so
then their is no benefit from RD ORF.  That being said if RR is not used
then the RD does not have to be unique pet VRF on a PE and so all VRFs
could have the same RD.  More dangerous in this case would allow you to ORF
RD filter all VPNs coming from a particular PE.  That does seem quite
dangerous and as it is a very unique case as RRs are almost alway used my
recommendation is to nix the ORF-RD.

Kind Regards

Gyan

On Tue, Aug 11, 2020 at 9:42 PM Aijun Wang <[email-masked]>
wrote:

> But, don’t’ you worry that if only one of the edge points being
> comprised/error-configured/attacked, then all of PEs within your domain are
> under risk?
>
> Furthermore, if you control different domains, and use Option-B/C to
> provide the inter-AS VPN services, such risk/”trashing routes” can easily
> spread among these domains?
>
> *From:* Gyan Mishra [mailto:[email-masked]]
> *Sent:* Wednesday, August 12, 2020 3:54 AM
> *Cc:* John E Drake <jdrake=[email-masked]>; Keyur Patel <
> [email-masked]>; Robert Raszuk <[email-masked]>; UTTARO, JAMES <
> [email-masked]>; idr <[email-masked]>; [email-masked]
> “Prefix Limit” mechanism can only protect the edge between PE-CE, can’t
> be deployed within PE that peered via RR.  We should not rely solely on the
> edge protection.
>
>
>

*Gyan Mishra*

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 12 Aug 2020 14:57:06 +0800

Hi, Gyan:

Sent: Wednesday, August 12, 2020 2:02 PM

Hi Aijun 

Standard practice for service providers is to have Infrastructure ACLs I call “Leaving the Kingdom” as when a packet enters or leaves the trusted SP domain it is a requirement per security posture for providers to secure the edge.  As far as config errors, centralized NMS controller for Restconf/Yang southbound policy push is the standard practice and that makes for ZTP and day to to day operations configuration changes error free.

[WAJ] This is just the “perimeter protection”, is useful but not enough.

As far as inter domain for opt B & C your control point is still your PE-CE protecting your edges from a control plane perspective and data plane perspective via infrastructure ACLs.  The NNI inter as link with option B is already a built in control point by design as you have to turn on retain-route-target all and then tie to a policy for interesting RTs to import as well as if their is an RT mismatch you have to manually via the same protection policy perform a RT-Rewrite.   

[WAJ] we are concerning the “trashing routes” from interested VRFs, not from the uninterested VRFs.

For Option C the SAFI 128 VPN control plane Is RR-RR so no RT filtering by default but not to worry as RTC takes care of the RR-PE advertisements.

I know your concern is with trashing of routes, however if you think about it “who originates the trashing routes” ?

So in this particular case it would be the provider outside of your administrative control.  

If it’s the inter-as is within a single administrative domain that is one thing but if it’s outside of the operators administrative domain and if this issue exists with certain RTs they have trashing routes or RD.  I do see your point with opt b and c.  

In those cases where you had an RT or RD that had trashing routes you could switch those to option-a back to back VRF and apply the maximum prefix filter. 

So I think we have narrowed the scope of the trashing routes to inter-as opt b or c going between administrative domains.  At that layer you cannot does the maxim prefix knob as it’s a VPN peer carrying all RTs.  So all you can do is filter on RTs.  

[WAJ] If the “trashing routes” from the interested VRF, filter on RTs will erase all prefixes from this VRF?

I do still stand by the per VRF maximum prefix knob as the first global control point that would be set on all PEs including the NNI inter-as boundary PEs and that would be your first line of defense against trashing routes.  

An example of how that would work is if you set the per VRF maximum to 100,000 prefixes.  Let’s say you get 1M+ prefixes on a 1000 different VRFs and that happened all simultaneously a coincidental flood with all the stars and moons in alignment.

[WAJ] But protect other VPNs in this PE from crashing.

The RD-ORF or RT-ORF is still working at the RD RT VPN layer and does not have the prefix level granularity as the PE-CE maximum prefix.

[WAJ] RD-ORF has the effect of PE-CE maximum prefix.

On every inter-as b c NNI if their was an RT that is thrashing you could adjust the RT filter / RT translation policy to not permit the RT doing the thrashing.

As far as the RD-ORF the RD is used to make the prefix unique 64 bit quantity so you can have overlapping prefixes within different VRFs unique by the RD.  As far as filtering their is no need to ever filter using RD.  That is never done in practice that I know of.  So I would remove that from the draft.  The RD is usually set to auto which makes it unique within a domain and of using a RR is required to be set to auto so that all the RDs originated by each PE has a different RD so that they all get reflected by the RR.  Without that sub optimal routing can occur as all paths are not reflected.  In that the case of RD auto making the RD unique per VRF so then their is no benefit from RD ORF.  That being said if RR is not used then the RD does not have to be unique pet VRF on a PE and so all VRFs could have the same RD.

[WAJ]  On one PE, different VRF will use different RD, or the address spaces from different VRF has the possibilities to collide.  If you can assure the address space unique within different VRFs, what the reason to use different VRFs then?

More dangerous in this case would allow you to ORF RD filter all VPNs coming from a particular PE.

[WAJ] If these VPNs on this PE, uses same RD(you assure the address space are non-overlapped),  what the harm that we filtered based on RD ? These VPNs act just like one VPN.

  That does seem quite dangerous and as it is a very unique case as RRs are almost alway used my recommendation is to nix the ORF-RD.

[WAJ] RR is always used, RD is often unique for each VRF on one PE. Then the scenarios that you described will not happen, what’s the dangerous then?

Kind Regards 

Gyan 

On Tue, Aug 11, 2020 at 9:42 PM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Gyan:

Best Regards

Aijun Wang

China Telecom

From: Gyan Mishra [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, August 12, 2020 3:54 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: John E Drake <jdrake=[email-masked] <mailto:[email-masked]> >; Keyur Patel <[email-masked] <mailto:[email-masked]> >; Robert Raszuk <[email-masked] <mailto:[email-masked]> >; UTTARO, JAMES <[email-masked] <mailto:[email-masked]> >; idr <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Aijun 

Kind Regards 

Gyan

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Aijun,

Thx,
R.

Best Regards

Aijun Wang

China Telecom

Agreed and good points.

Thanks 

Gyan

Thanks,

              Jim Uttaro

Hi Authors 

 

RTC to the rescue!! 

Kind Regards 

Gyan

Hi,

Yours Irrespectively,

John

 

Kind regards,

Robert

Hi, Robert and Gyan:

 

Best Regards

Aijun Wang

China Telecom

Folks,

Many thx,

R.

 

Hi, Gyan and Robert:

   

Aijun Wang

China Telecom

 

Hi Robert 

Kind Regards 

Gyan

Hi Gyan,

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Aug 2020 11:59:36 +0200

Aijun,

> comprised/error-configured/attacked, then all of PEs within your domain are

First if one PE is compromised new RD can be created or routes injected
into global table completely destroying your entire network. No matter how
much protocol extensions we will define here if your network infrastructure
is attacked and the attack is successful you are over.

Now we keep telling you that any decent L3VPN or L2VPN implementation has
two completely different protections - shipping and successfully protecting
production networks:

Protection 1 - BGP prefix limit

Protection 2 - VRF limit

If you enable correctly those two checks you are pretty safe.

If not I recommend you offer CSC model and do not take any external routes
into your core infrastructure. Of course you can still carry routes for
your customers except that they will be distributed with no risk to your
core or PEs "over the top". PEs in this case *only* handle directly
connected next hops which I hops is pretty trivial to protect.

Many thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 12 Aug 2020 10:56:01 -0400

Hi Aijun

See in-line responses.

Service Providers networks are built to be robust enough to carry customer
prefixes and account for flood of routes.

The layers of protection are basic standard protection mechanisms for any
SP core public or private.

1.  Infrastructure security ACLs on PE-CE links.

2.  RTC on PE-RR to only advertise interesting RTs defined on PEs based on
import policy.

3.  Per VRF maximum prefix setting based on edge node resources.

4.  PE-CE edge peer maximum prefix

5. Inter AS Opt B RT level protection for rewrite or limit interesting RTs
to be accepted.

The main point is the SP router infrastructure is built to account for edge
flood of prefixes intra or inter-as
within any given edge or SP.  The protection mechanisms above have address
all the issues of prefix flooding and has been the basic a used for years.

Maybe first documenting actual use cases with a problem statement draft
that depicts the providers that had the problems you are describing and the
impact and why the solutions above did not resolve the issue.

I think that is a first step as most all the responses on the ML are
stating that the above has historically solved the issues described.

I am the lead architect and SME for Verizon a tier 1 carrier which carries
tremendous weight as a stakeholder worldwide and we have used these basic
standard best practices for years since the inception of MPLS IP VPNs 20+
years ago.  We have not run into any of the problems you are mentioning.

Thanks

Gyan

On Wed, Aug 12, 2020 at 2:57 AM Aijun Wang <[email-masked]>
wrote:

> *Sent:* Wednesday, August 12, 2020 2:02 PM
> *[WAJ] This is just the “perimeter protection”, is useful but not enough.*
>
          Gyan> I don’t understand why that does not work for you.

>
>
> As far as inter domain for opt B & C your control point is still your
> PE-CE protecting your edges from a control plane perspective and data plane
> *[WAJ] we are concerning the “trashing routes” from interested VRFs, not
> from the uninterested VRFs.*
>

          Gyan> I understand and even with the RTs imported you can still
define the per VRF maximum prefix in the RT translation case or existing
RTs on the ASBR as well as the PEs in the domain importing the routes.

> In those cases where you had an RT or RD that had trashing routes you
> could switch those to option-a back to back VRF and apply the maximum
> prefix filter.
>
>
>
> *[WAJ] If the “trashing routes” from the interested VRF, filter on RTs
> will erase all prefixes from this VRF?*
>
>  Gyan> Understood, however you also have the per VRF maximum prefix that
> you can set on the RTs imported from the other providers.
>
> *[WAJ] But protect other VPNs in this PE from crashing.*
>
>  Gyan> I don’t understand the crashing.  Is that crashing of the router.
> What would happen is the routes above the maximum would be clipped and
> dropped.
>
> *[WAJ] RD-ORF has the effect of PE-CE maximum prefix.*
>
>  Understood.  I think you need a study of service providers to depict why
> the list of mentioned protection mechanisms won’t work for you.
>
> could have the same RD.
> *[WAJ]  On one PE, different VRF will use different RD, or the address
> spaces from different VRF has the possibilities to collide.  If you can
> assure the address space unique within different VRFs, what the reason to
> use different VRFs then?*
>
>  Gyan> I mis stated the RD scenario.  Sorry. The RD can be the same on all
> PEs within a VPN or different per PE within the same VPN on the VRF
> definition.  When RR is utilized the RD must be set to Auto which is the
> standard practice so the the VPN routes from different PEs within the same
> VPN can be reflected within the VRF which can only be possible if the RD is
> different.  L3 VPN does not have the option of “add path” as does SAFI 1 so
> you must do RD auto for the RR route reflection to work on a per path
> basis. So the RD as stated has to  be different per VRF as that is what
> makes the prefix unique and each prefix can have many RTs tagged to the
> prefix if it is imported into many different VRFs.  Your draft addresses
> the RR scenario to use the RD-ORF prefix filtering feature.  So now the RD
> in the RR scenario now references the source  per PE VPN routes advertised
> to the RR and does not represent all PEs as the RD must be unique by RD
> auto set to type 1 RD IP:Y.  So your policy would be matching the Type 1
> RD.
>
More dangerous in this case would allow you to ORF RD filter all VPNs
> coming from a particular PE.
>
> *[WAJ] If these VPNs on this PE, uses same RD(you assure the address space
> are non-overlapped),  what the harm that we filtered based on RD ? These
> VPNs act just like one VPN.*
>
>
>
          Gyan> See above comment

>
>
>   That does seem quite dangerous and as it is a very unique case as RRs
> are almost alway used my recommendation is to nix the ORF-RD.
>
> *[WAJ] RR is always used, RD is often unique for each VRF on one PE. Then
> the scenarios that you described will not happen, what’s the dangerous
> then?*
>
> Gyan> See comments above addresses this.
>
> Kind Regards
>
>
>
> Gyan
>
>
>

*Gyan Mishra*

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 13 Aug 2020 11:44:52 +0800

Hi, Gyan:

Sent: Wednesday, August 12, 2020 10:56 PM

Hi Aijun

See in-line responses.  

Service Providers networks are built to be robust enough to carry customer prefixes and account for flood of routes.  

The layers of protection are basic standard protection mechanisms for any SP core public or private.

2.  RTC on PE-RR to only advertise interesting RTs defined on PEs based on import policy.

[WAJ] You mean to configure VRF maximum prefix on the PE-RR BGP session? What you will do when the limit is exceeded? 

a)     Breaking down the BGP session with RR?  Will influence other VRFs on this PE.

b)    Warning Only? The received PE will be busying to dealing the afterward overloading routes, exacerbate the situation then?

5. Inter AS Opt B RT level protection for rewrite or limit interesting RTs to be accepted.

The main point is the SP router infrastructure is built to account for edge flood of prefixes intra or inter-as 

within any given edge or SP.  The protection mechanisms above have address all the issues of prefix flooding and has been the basic a used for years.

Maybe first documenting actual use cases with a problem statement draft that depicts the providers that had the problems you are describing and the impact and why the solutions above did not resolve the issue.

I think that is a first step as most all the responses on the ML are stating that the above has historically solved the issues described.

[WAJ] We will add more contents in the updated draft to reflect the response on the ML.

I am the lead architect and SME for Verizon a tier 1 carrier which carries tremendous weight as a stakeholder worldwide and we have used these basic standard best practices for years since the inception of MPLS IP VPNs 20+ years ago.  We have not run into any of the problems you are mentioning.

[WAJ] Actually, we write this draft mainly for EVPN over VxLAN/SRv6 inter-AS scenario, where the Option-B/C will be preferred, instead of Option-A as in MPLS-VPN.  But the VPN route trashing possibilities exists also within one AS.

Thanks 

Gyan

On Wed, Aug 12, 2020 at 2:57 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Gyan:

 

Hi Aijun 

          Gyan> I understand and even with the RTs imported you can still define the per VRF maximum prefix in the RT translation case or existing RTs on the ASBR as well as the PEs in the domain importing the routes.

 Gyan> Understood, however you also have the per VRF maximum prefix that you can set on the RTs imported from the other providers.

 Gyan> I don’t understand the crashing.  Is that crashing of the router.  What would happen is the routes above the maximum would be clipped and dropped.

 Understood.  I think you need a study of service providers to depict why the list of mentioned protection mechanisms won’t work for you.

 Gyan> I mis stated the RD scenario.  Sorry. The RD can be the same on all PEs within a VPN or different per PE within the same VPN on the VRF definition.  When RR is utilized the RD must be set to Auto which is the standard practice so the the VPN routes from different PEs within the same VPN can be reflected within the VRF which can only be possible if the RD is different.  L3 VPN does not have the option of “add path” as does SAFI 1 so you must do RD auto for the RR route reflection to work on a per path basis. So the RD as stated has to  be different per VRF as that is what makes the prefix unique and each prefix can have many RTs tagged to the prefix if it is imported into many different VRFs.  Your draft addresses the RR scenario to use the RD-ORF prefix filtering feature.  So now the RD in the RR scenario now references the source  per PE VPN routes advertised to the RR and does not represent all PEs as the RD must be unique by RD auto set to type 1 RD IP:Y.  So your policy would be matching the Type 1 RD.  

          Gyan> See above comment

Kind Regards 

Gyan 

Hi, Gyan:

Best Regards

Aijun Wang

China Telecom

Aijun 

Kind Regards 

Gyan

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Aijun,

Thx,
R.

Best Regards

Aijun Wang

China Telecom

Agreed and good points.

Thanks 

Gyan

Thanks,

              Jim Uttaro

Hi Authors 

 

RTC to the rescue!! 

Kind Regards 

Gyan

Hi,

Yours Irrespectively,

John

 

Kind regards,

Robert

Hi, Robert and Gyan:

 

Best Regards

Aijun Wang

China Telecom

Folks,

Many thx,

R.

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 13 Aug 2020 07:14:34 -0400

On Wed, Aug 12, 2020 at 11:44 PM Aijun Wang <[email-masked]>
wrote:

> *Sent:* Wednesday, August 12, 2020 10:56 PM
> *[WAJ] You mean to configure VRF maximum prefix on the PE-RR BGP session?
> What you will do when the limit is exceeded? *
>
> *a)     **Breaking down the BGP session with RR?  Will influence other
> VRFs on this PE.*
>
                         No.  This is on the VRF global configuration for
per VRF maximum prefix for the VRF RIB

> *b)    **Warning Only? The received PE will be busying to dealing the
> afterward overloading routes, exacerbate the situation then?*
>

                   I think you are confusing peer maximum prefix with
global VRF level maximum prefix.

                    The warning option is there for peer maximum prefix
command which is why I think you maybe confused.

> *[WAJ] We will add more contents in the updated draft to reflect the
> response on the ML.*
>
>
>
> *[WAJ] Actually, we write this draft mainly for EVPN over VxLAN/SRv6
> inter-AS scenario, where the Option-B/C will be preferred, instead of
> Option-A as in MPLS-VPN.  But the VPN route trashing possibilities exists
> also within one AS.*
>
> That does make a difference and maybe you should state in the draft also I
> think maybe exclude MPLS vpn.
>
> Thanks
>
>
>
> Gyan
>
>
>
> call “Leaving the Kingdom” as when a packet enters or leaves the trusted
> SP domain it is a requirement per security posture for providers to secure
> the edge.  As far as config errors, centralized NMS controller for
> *[WAJ] This is just the **“perimeter protection”, is useful but not
> enough.*
>
> *[WAJ] we are concerning the **“trashing routes” from interested VRFs,
> not from the uninterested VRFs.*
>
>
>
> does the maxim prefix knob as it’s a VPN peer carrying all RTs.  So all
> you can do is filter on RTs.
>
> *[WAJ] If the **“trashing routes” from the interested VRF, filter on RTs
> 100,000 prefixes.  Let’s say you get 1M+ prefixes on a 1000 different
> VRFs and that happened all simultaneously a coincidental flood with all the
> different.  L3 VPN does not have the option of “add path” as does SAFI 1
> so you must do RD auto for the RR route reflection to work on a per path
> the scenarios that you described will not happen, what**’s the dangerous
> then?*
>
> data plane where the RRs are dedicated control plane function and don’t
> *From:* Idr <idr-bounces@i <[email-masked]>
>
> --

*Gyan Mishra*