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

Hi, Jim:

Aijun Wang
China Telecom

> On Feb 10, 2021, at 23:02, UTTARO, JAMES <ju1738@att.com> wrote:
> 
> 
> TBH looks like a solution in search of a problem.
[WAJ] I think you may not get the key scenarios that the draft aims to solve.
>  
> The tools used for the last 20+ yrs. to prevent a mis-behaving CE or peer are proven.
[WAJ]Yes, we also analyze them in the introduction parts of this document, they don’t fit the described scenarios.
>  
> 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.
[WAJ] Yes, RR is just reflector.
> 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?
[WAJ] There are many reasons for the misbehaving PE to send overwhelming VPN routes. The RD-ORF mechanism just want to limit its bad influences to the least.
>  
> 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.
[WAJ] Controlling the excess BGP updates is the primary aim of ORF mechanism. RD-ORF is just one new type of ORF.

> 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.
[WAJ] The overflow of customer VRF can be solved via the BGP Maximum Prefix mechanism. RD-ORF is not for such situation.
>  
> 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?
[WAJ]RD-ORF does not overloading the semantics of RD. It has not specific requirements for assigning RD. The RD can be unique for a VPN on each PE, or keep same for the same VPN on different PEs.
>  
> Thanks,
>               Jim Uttaro
>  
>  
>  
>  
> From: Aijun Wang <wangaijun@tsinghua.org.cn> 
> Sent: Wednesday, February 10, 2021 9:17 AM
> To: UTTARO, JAMES <ju1738@att.com>
> Cc: Lizhenbin <lizhenbin@huawei.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org
> 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 <ju1738@att.com> wrote:
> 
> 
> Do Not Support.
>  
> Thanks,
>               Jim Uttaro
>  
> From: Idr <idr-bounces@ietf.org> On Behalf Of Lizhenbin
> Sent: Wednesday, February 10, 2021 4:47 AM
> To: Susan Hares <shares@ndzh.com>; idr@ietf.org
> 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:idr-bounces@ietf.org] On Behalf Of Susan Hares
> Sent: Thursday, February 4, 2021 11:38 PM
> To: idr@ietf.org
> 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/..
>  
> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr