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

[Robert Raszuk <[e-mail]>]

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)

* protection at the VRF level at the src PE (no new spec needed)

Then claim is now stated that operator can not control src PE. That's an
interesting claim. We in many routing protocols assume that there is
control within domain. For Interdomain again we should apply prefix limit
on a per RD basis. (if they would provide a draft suggesting this I would
highly support it).

Then last the issue can be clearly mitigated by network management layer.

Just pushing ORF to adjacent RR and not mitigating the issue is not a
proper action.

Thx,
R.













On Mon, Aug 29, 2022 at 10:29 AM Susan Hares <[e-mail]> wrote:

> Robert:
>
>
>
> You might consider that Aijun and others do not have the ability to
> quickly take the rogue PE out of the network.
>
>
>
> Asking Aijun why they do not take the Rogue PE out of the network – may be
> useful.
>
>
>
> Sue
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Friday, August 26, 2022 6:48 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* Acee Lindem (acee) <[e-mail]>; idr@ietf. org <[e-mail]>;
> Susan Hares <[e-mail]>
> *Subject:* Re: [Idr] Adoption and IPR call for
> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>
>
>
>
>
>
>
> I admit there will be no single solution for one problem.
>
>
>
> The role of IETF is to standardize a single solution to real problems. At
> least we should aim for that.
>
>
>
> Your problem description is this:  *"rogue PE"*
>
>
>
> Well to me this is not sufficiently precise to convince anyone that there
> is a problem to start with. At least I am happy to see that you are no
> longer stating that the problem you are trying to protect from is "rogue
> CE" (as clearly PE-CE prefix limit will effectively mitigate it
> at its source).
>
>
>
> Bottom line is this - if we assume that any PE can arbitrarily misbehave
> and inject bogus stuff in the routing control plane then we have a much
> larger problem. And IMO the right solution to such a problem would be to
> take such "rogue PE" out of the network ASAP. Not to cherry pick who's VPN
> to cut first, second, third on RRs in the path.
>
>
>
> Rgs,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>