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

["Jakob Heitz (jheitz)" <[e-mail]>]

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.
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.

But really, the overwhelmed router can just drop its own routes.
What difference does it make to send an ORF?
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.

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.

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.

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

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.

Kind regards,
Robert

On Wed, Feb 10, 2021 at 8:24 PM Acee Lindem (acee) <acee=[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr