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=
40cisco.com@dmarc.ietf.org> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>