Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

[Linda Dunbar <[e-mail]>]

Jim,

You said
“Generally speaking I do not want my RRs making a best path decision for a given path.”
Isn’t RFC4684 (Constrained Route Distribution) doing the same? i.e. allowing RR to constraint the route distribution to some nodes?

Linda Dunbar
From: Idr <[e-mail]> On Behalf Of UTTARO, JAMES
Sent: Wednesday, February 10, 2021 9:02 AM
To: Aijun Wang <[e-mail]>
Cc: [e-mail]; Susan Hares <[e-mail]>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

TBH looks like a solution in search of a problem.

The tools used for the last 20+ yrs. to prevent a mis-behaving CE or peer are proven.

An example:

“When the VRF of VPN1 in PE1 overflows, due to PE1 and other PEs are
   not iBGP neighbors, BGP Maximum Prefix Features cannot work, so the
   problem on PE2 cannot be known.”

My take on this very first premise is that a VRF ( VPN1 ) on PE1 is being overwhelmed with routes. These routes are not coming from the RR topology. So what is the scenario ? Is it a redistribution from VRF ( VPN2 )->VRF( VPN1 )? If so, you have a serious security issue.. Is it redistribute from another protocol, the GRT?

I disagree with your premise that the current suite of mitigations are not sufficient..  There are certain assertions which are subjective and not appropriate. AN example:

“4) Configure the Maximum Prefix for each VRF on edge nodes

   When a VRF overflows, it stops the import of routes and log the extra
   VPN routes into its RIB.  However, PEs should parse the BGP updates.
   These processes will cost CPU cycles and further burden the
   overflowing PE.”

What does this mean? There are networks that have been parsing millions of BGP Updates and routes. I have seen VRF overflows and they have been specific to said customer’s VRF. Where are you coming up with this and other broad assertions.

From a solution point of view I do not believe in overloading the object. IOW RD is meant to convey uniqueness of a given path through a topology, overloading it with this semantic means what to the existing semantic.. As an ex, some operators use unique RD so there is no path hiding, eibgp load balancing etc.. Generally speaking I do not want my RRs making a best path decision for a given path. Some do not use unique RD for there own reasons including scale, possible alignment of RR topology to underlying best path etc…

In order to use this technology what are the requirements in terms of assigning RDs?

Thanks,
              Jim Uttaro




From: Aijun Wang <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, February 10, 2021 9:17 AM
To: UTTARO, JAMES <[e-mail]<mailto:[e-mail]>>
Cc: Lizhenbin <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Hi, Jim:

Would you like to elaborate your considerations in detail?
We can try to address your concerns via the mail list or updating the draft if you have reasonable comments.

Thanks in advance.

Aijun Wang
China Telecom

On Feb 10, 2021, at 20:35, UTTARO, JAMES <[e-mail]<mailto:[e-mail]>> wrote:

Do Not Support.

Thanks,
              Jim Uttaro

From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Lizhenbin
Sent: Wednesday, February 10, 2021 4:47 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Hi All,

I support the adoption.
1) Yes
2) Yes
3) Yes

Best Regards,
Zhenbin (Robin)




From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Thursday, February 4, 2021 11:38 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

This begins a 2 week WG adoption call for draft-wang-idr-rd-orf-05.txt (from 2/4/2021 to 2/18/2021)

This draft defines a new Outbound Route Filter (ORF) type, called the
Route Distinguisher ORF (RD-ORF).  RD-ORF is applicable when the
routers do not exchange VPN routing information directly (e.g.
routers in single-domain connect via Route Reflector, or routers in
Option B/Option AB/Option C cross-domain scenario).

Please be aware that this draft has one IPR statement attached.

https://datatracker.ietf.org/ipr/4579/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fipr%2F4579%2F__%3B!!BhdT!3JFUDaX3WxfXuq0-jDevFeHNv4xKPBpOZ-cktrZ8Hg9b1Ipaj0PIHJh3ZFw%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cf60eff6157cf443002f808d8cdd4ea11%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637485661658520629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=V8BLv2ehjuO5B5gwcVNl8GfE8GjAoXfN7Vjy0huOrLA%3D&reserved=0>..

Please consider the following questions in your review and comments:

1) Will this new ORF filter reduce routing information at key points?
2) Should the WG consider this draft given it has an IPR claim or
    Would the IDR WG prefer another approach?
3) Is this draft ready to be adopted and refined as WG draft?

Cheerily, Susan Hares


_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr__%3B!!BhdT!yysdkGCNAgoHWvY47NKedcAHI_Yf6MRpOT4zgCSp7HcB9m4Q73F8OU36k5sDVys%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cf60eff6157cf443002f808d8cdd4ea11%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637485661658520629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Lh3QmctDwsAWCcPVxUcsPwfkS2VhpRsGz5X2hjfajQk%3D&reserved=0>