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:

Aijun Wang
China Telecom

> On Feb 11, 2021, at 10:49, Jakob Heitz (jheitz) <[e-mail]> wrote:
> 
> 
> The Cisco implementation is not the only possible embodiment of an RFC.
> Cisco does not prevent you from using an encoding that an RFC allows.

[WAJ] Not only Cisco, but also Huawei and Juniper, take similar approach to implement Prefix-base ORF. The prefix is the portion of user interested, which is described via Prefix-List.
>  
> The RFC does not specify what is to trigger the emission of the ORF.
> It may be by static configuration or as a result of your procedure.

[WAJ] Yeah. Trigger and procedures of the new ORF type is the major part of this document because we want to solve the situation that we can’t know in advance.

What you and Robert want to reuse is the semantic of prefix-based ORF type encoding. If we reuse it, most part of its fields has no meaningful or must set one special value , and to keep it in more general, we must make clear statements about the value of each filed in various address families, as that done in RFC7543.
Don’t you think RD-ORF is one clear slate to achieve the goal? And we have almost finished it?

>  
> In your draft, each BGP speaker makes an independent decision:
> If a speaker has no use for a set of routes prefixed by a specific RD
> in a specific address family, it sends an ORF to the originators of
> that set of routes. "use for a set of routes" means either for its own
> use or to propagate to other neighbors. The speaker can decide
> that it has no use for a set of routes based upon either style of ORF.
> The ORF needs no special semantic to make that work.

[WAJ] Current draft is not only for semantic encoding, but also the trigger and procedures, which is lack in RFC 5292. 
For encoding itself, as explained above, reusing the existing one has no direct gain, but only confusion.

>  

> Regards,
> Jakob.
>  
> From: Idr <[e-mail]> On Behalf Of Aijun Wang
> Sent: Wednesday, February 10, 2021 5:36 PM
> To: Jakob Heitz (jheitz) <jheitz=[e-mail]>
> Cc: [e-mail]; Susan Hares <[e-mail]>; Robert Raszuk <[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)
>  
> 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