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

[Aijun Wang <[e-mail]>]

Hi, Jakob and Robert:


Aijun Wang
China Telecom

> On Feb 11, 2021, at 08:23, Jakob Heitz (jheitz) <jheitz=[e-mail]> wrote:
> 
> 
> I agree with Robert.
> The draft is not necessary.
> Existing ORF from RF5292 can be used by using an address-prefix ORF in the VPN address family with prefix length 64.
> The length 64 covers the RD portion of the prefix.
[WAJ]  Would you like to see https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/irg-oubound-route-filtering.html for the usage of BGP prefixes based ORF that provided by Cisco. In this example, we focus mainly on the real portion of the VPN routes(the prefix-list itself), there is no RD portion mentioned.
Theoretically, the RD is part of the prefix, but don’t you think reuse the prefix based ORF to accomplish the RD-ORF effects changes the semantics of its main usage and arise chaos in implementation?
We should also know that even we reuse the semantic of prefix based ORF, there is no procedure to achieve the same effects that described in this draft. The usage of prefix based ORF is coming from the static, in advance configuration, which is not the aim of RD-ORF.

> The elements of procedure in the draft are new. However, an RFC is not needed for that.
> It is a local feature on each router.
[WAJ] ORF mechanism is not only the local feature on each router. It is the negotiation feature between peer router.
>  
> But really, the overwhelmed router can just drop its own routes.
> What difference does it make to send an ORF?
[WAJ] Once sent, the overwhelmed router need not do the unnecessary BGP updates parsing then.

> ORF seems to be a very little used feature.
> The only question I remember getting about ORFs is "How can we limit the number of ORFs we accept from a neighbor?".
> Operators don't like getting ORFs. They worry that it stresses their box.
[WAJ] Actually, the solution come mainly from the Option B/C inter-AS VPN deployment scenarios. For MPLS, the Option B/C inter-AS VPN are not deployed widespread, one reason I think is the control of VPN routes propagation within each VPN.(there are maybe other reasons, for example the distribution of MPLS label).
But for EVPN/VXLAN or EVPN/SRv6, the flexibility of  inter-AS deployment is its advantage. Based on such judgement, we think along the widespread of Option B/C deployment, the control mechanism for the restraining of overwhelm VPN routes should be emergency.

Additional replies to Robert are inline below[WAJ]


>  
> Regards,
> Jakob.
>  
> From: Idr <[e-mail]> On Behalf Of Robert Raszuk
> Sent: Wednesday, February 10, 2021 12:52 PM
> To: Susan Hares <[e-mail]>
> Cc: [e-mail]; Acee Lindem (acee) <acee=[e-mail]>
> Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
>  
> Dear Sue & WG,
>  
> Technically the solution is broken - you can't filter based on RD when single VRF overflows due to simple fact that arriving routes at a PE with one RD are typically imported locally to many different VRFs which may be running just fine. That to me is sufficient to dismiss this proposal. 
[WAJ] As Jim also mentioned, the redistribution between different VRFs is poor design and we should avoid it in first place.
Even for your situation, the document has already mentioned possible solution(in the end of section 5.1.1) which can be further investigated if necessary. We are also welcome your contribution to the case that you are concerning.
>  
> I am not even going to point out that for multihomed sites injecting both aggregates and more specifics + doing eiBGP load balancing or sharing similar mixed reachability with Inter-AS option B could  form a rather ugly data plane behaviour. 
[WAJ] This is related to the complex traffic engineering and need other tools or AI mechanism to solve. The IETF is just providing the tool to assist the aim achievement. Don’t you think so?
>  
> But putting those (one could say subjective claims) aside procedurally what is important here is that *entire*  protocol extension this draft is attempting to define is already defined for a long time in a RFC ... namely RFC5292 -> https://tools.ietf.org/html/rfc5292
>  
> So it would be pretty bad precedence to now define subset of it in other RFC. And what if both ORF types are used together ? Hint: VPNv4/v6 PREFIX==RD+NET
>  
[WAJ] Please see the above explanation to Jakob.

> At best this draft could be turned into an informational document titled: "How to shoot yourself in the foot while using prefix ORF to filter VPN routes".  which I would support adoption of.  
[WAJ] Can consider adding one section to describe the consequences when using prefix ORF to filter VPN routes if necessary.
Or, is the responses for Jakob addressing your concern?
>  
> Kind regards,
> Robert
>  
> On Wed, Feb 10, 2021 at 8:24 PM Acee Lindem (acee) <acee=[e-mail]> wrote:
> Hi Sue, IDR WG,
>  
> I agree with Jim Uttaro with respect to the use case being weak and already solved with other mechanisms.
>  
> Also, there was much opposition to changing the RD semantics and using it for route filtering. See:
>  
> https://mailarchive.ietf.org/arch/browse/idr/?q=%22wang-idr-rd-orf%22
>  
> I don’t see that this has changed and, additionally, this will add further complexity to BGP route filtering dynamics.
> Thanks,
> Acee
>  
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr