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

Hi Robert

On Mon, Aug 29, 2022 at 5:23 AM Robert Raszuk <robert@raszuk.net> 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)
>

   Gyan> The issue historically has been with VRF maximum prefix and PE-CE
maximum prefix and that  we all agreed from the last few adoption calls is
existing mechanisms don’t suffice for this overflow issue due to the limit
for both being set to a  generic high water mark by operators taking into
account statistical multiplexing 80/20 rule and oversubscribing the limits
to avoid OPEX costs of administrative overhead of having to continually
adjust the limits.  Configuration templates are pushed via standard policy
from NMS so it’s very generically done.  So this is a real issue to be
solved and now it’s digging into the solution space to solve it as best
possible.  The issue related to RD based ORF was resolved using now a 3
tuple {RT, RD, origin  prefix) RD+TLV combo from WG feedback.  The issue
with dropping of routes related to source PE is being addressed as Aijun
pointed out with regards the clarifications on use of the quota and use of
optimization of ORF to only drop the overflowing routes not all routes.

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

   Gyan> The solution applies to intra domain and inter domain inter-as
options b and c per RD / prefix basis.

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

   Gyan> Difficulty with management layer is detecting the overflow issue
which with protocol extension can easily be done natively with VPN ORF.

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

    Gyan>The draft addresses both mitigation to adjacency RR as well as
upstream to source PE using the source PE TLV.

>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Aug 29, 2022 at 10:29 AM Susan Hares <shares@ndzh.com> 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 <robert@raszuk.net>
>> *Sent:* Friday, August 26, 2022 6:48 PM
>> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
>> *Cc:* Acee Lindem (acee) <acee@cisco.com>; idr@ietf. org <idr@ietf.org>;
>> Susan Hares <shares@ndzh.com>
>> *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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*