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

[Robert Raszuk <[e-mail]>]

> 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 <[e-mail]> 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 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) <[e-mail]> wrote:
>
> 
> 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 **J*
>
>
>
> Kind regards,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Aug 5, 2020 at 4:34 AM Aijun Wang <[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]] *On Behalf Of *
> [e-mail]
> *Sent:* Tuesday, July 28, 2020 4:47 PM
> *To:* idr <[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]
> ------------------------------------------------------------------------
> CTNET2025研究所
> 中国电信股份有限公司北京研究院
> China Telecom Corporation Limited Beijing Research Institute
> 北京市昌平区北七家镇未来科技城南区中国电信北京信息科技创新园
> 邮编：102209
>
>
>
> *From:* internet-drafts <[e-mail]>
>
> *Date:* 2020-07-28 16:17
>
> *To:* Jie Dong <[e-mail]>; Aijun Wang <[e-mail]>;
> Shunwan Zhuang <[e-mail]>; Wei Wang
> <[e-mail]>; Haibo Wang <[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.
>
>
>
> The IETF Secretariat
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>