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

["Rajiv Asati (rajiva)" <[e-mail]>]

Aijun,

Pls see inline ,

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

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 <[e-mail]> wrote:


Hi, Robert:

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

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

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

Kind regards,
R.
















On Wed, Aug 5, 2020 at 4:34 AM Aijun Wang <[e-mail]<mailto:[e-mail]>> wrote:
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, July 28, 2020 4:47 PM
To: idr <[e-mail]<mailto:[e-mail]>>
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
[phone]
[phone]
[e-mail]<mailto:[e-mail]>
------------------------------------------------------------------------
CTNET2025研究所
中国电信股份有限公司北京研究院
China Telecom Corporation Limited Beijing Research Institute
北京市昌平区北七家镇未来科技城南区中国电信北京信息科技创新园
邮编：102209

From: internet-drafts<mailto:[e-mail]>
Date: 2020-07-28 16:17
To: Jie Dong<mailto:[e-mail]>; Aijun Wang<mailto:[e-mail]>; Shunwan Zhuang<mailto:[e-mail]>; Wei Wang<mailto:[e-mail]>; Haibo Wang<mailto:[e-mail]>
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<http://tools.ietf.org>.

The IETF Secretariat



_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr