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

[Robert Raszuk <[e-mail]>]

Aijun,

Properly implemented protection mechanisms which are in place today do
protect also from accidental misconfigurations.

But if the reason for this draft u
is as stated in this threat that intradomain you can not control your own
PEs then we have a much bigger problem.

Thx
R.

On Mon, Aug 29, 2022, 12:13 Aijun Wang <[e-mail]> wrote:

> Hi, Robert:
>
> The solution for intra domain is the base for the future inter domain
> scenario. I think you should know the original version of our draft.
> And, even within the intra domain, you cannot prevent there may be
> misconfiguration. The proposal mechanism just want to relieve the operator
> from the unexpected overflowing routes, which can influence other VPNs that
> are sharing the same BGP sessions.
> The management is necessary but we can’t depend solely on it.
>
> Aijun Wang
> China Telecom
>
> On Aug 29, 2022, at 17:52, 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)
>
> * 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>