Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

[Robert Raszuk <[e-mail]>]

Jeff,

> and instead focus on the technical correctness of the solution.

Technically the proposed solution in version -03 under adoption is
incorrect.

If the problem is detected it should be communicated to the src and
mitigated at the src not at the mid points.

Such communication could be done via mgmt plane or with the assistance of
routing protocol.

Best regards,
Robert


On Mon, Aug 29, 2022 at 1:17 PM Jeffrey Haas <[e-mail]> wrote:

>
>
> On Aug 29, 2022, at 5:22 AM, Robert Raszuk <[e-mail]> wrote:
>
> Sue,
>
> > You might consider that Aijun and others do not have the ability to
> quickly take the rogue PE out of the network.
>
> No one is suggesting that.
>
> The current methods to mitigate the issue are as stated number of times:
>
> * local drop of overflowing routes at the weak PE  (no new spec needed)
>
> * protection at the PE-CE boundary at the src PE (no new spec needed)
>
>
> Also known as local incoming policy?
>
> From RFC 5291:
>
> 1 <https://www.rfc-editor.org/rfc/rfc5291.html#section-1>.  Introduction
>
>    Currently, it is not uncommon for a BGP speaker [BGP-4 <https://www.rfc-editor.org/rfc/rfc5291.html#ref-BGP-4>] to receive,
>    and then filter out some unwanted routes from its peers based on its
>    local routing policy.  Since the generation and transmission of
>    routing updates by the sender, as well as the processing of routing
>    updates by the receiver consume resources, it may be beneficial if
>    the generation of such unwanted routing updates can be avoided in the
>    first place.
>
>
> You might not like the feature Robert, but it's exactly what ORF was
> designed for.
>
> It'd be beneficial to the working group to cease this endless questioning
> of the use case (that you don't like) and instead focus on the technical
> correctness of the solution.
>
> -- Jeff
>
>