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

Some additions. In the offered model when a PE sends a notification based
on its preconfigured limits, there is no option for AD, so this moment is
not actual. But the problem is still actual. It's not clear to me why we
need to preconfigure some quota per every possible source PE. Reading the
draft and the analysis document didn't shed the light.
I'm really sorry if this question was raised and was answered previously.
If it is so a link to the conversation would be great :)

сб, 20 авг. 2022 г. в 12:54, Igor Malyushkin <gmalyushkin@gmail.com>:

> Hi all,
>
> This draft requires configuring limits for every possible VRF on a PE with
> every possible pair of "source PE, RD" for these VRFs. For many
> deployments, such an approach leads to an operation burden. From my
> perspective, it is desirable to have some auto-discovery mechanism for
> these limits if the community is going to proceed with this draft.
>
> Also, Section 5.1 states:
>   In single-domain or Option C cross-domain scenario, NEXT_HOP attribute
> is unchanged during routing transmission, so it can be used as source
> address.
>
> It is not actually true. There are some deployments using different
> next-hops for outbound VPN routes belonging to a single PE-VRF pair (e.g.,
> core diversity pattern). Thus, there should be a more precise definition of
> a source PE that is absolutely decoupled from the NEXT_HOP attribute.
>
> сб, 20 авг. 2022 г. в 12:41, UTTARO, JAMES <ju1738@att.com>:
>
>> *I do not support adoption of this draft. *
>>
>>
>>
>> *Thanks,*
>>
>> *          Jim Uttaro*
>>
>>
>>
>> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of * Robert Raszuk
>> *Sent:* Saturday, August 20, 2022 4:28 AM
>> *To:* Susan Hares <shares@ndzh.com>
>> *Cc:* idr@ietf.org; Zhuangshunwan <zhuangshunwan=
>> 40huawei.com@dmarc.ietf.org>
>> *Subject:* Re: [Idr] Adoption and IPR call for
>> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>>
>>
>>
>> Hi,
>>
>>
>>
>> > and all the comments raised in the IDR list have been addressed
>>
>>
>>
>> That is not true.
>>
>>
>>
>> For the record I am still opposing adoption of this draft.
>>
>>
>>
>> Sample list of issues which were not addressed:
>>
>>
>>
>> #1 - RD allocation can be per VRF or Global in a given VPN. This scheme
>> works only in the case of per VRF allocation.
>>
>>
>>
>> #2 - Filtering by src RD can result in loss of reachability to other VPNs
>> on a given node which only import subset of routes.
>>
>>
>>
>> #3 - Use of prefix ORF can be applied where prefix is just /64 RD without
>> any new draft. The draft says:
>>
>>
>>
>>
>>
>> *Using Address Prefix ORF to filter VPN routes need to pre-
>>  configuration, but it is impossible to know which prefix may cause
>>  overflow in advance.*
>>
>>
>>
>>     .. which clearly is not correct as irrespective on the encoding you
>> need to know what RD to push.
>>
>>     Here in this context of RFC5292 PREFIX == RD == /64 PREFIX
>>
>>
>>
>> #4 - Change of ORF list results in advertisement of ALL routes of a a
>> given AFI/SAFI to the peer.
>>
>>         That is the same irrespective if IMMEDIATE or DEFER flags are
>> set. That puts burden on the peer especially in
>>
>>         VPN cases when the number of routes may be high.
>>
>>
>>
>> #5 - Sender of ORF does not know when it is safe to remove the filter.
>> Manual action is still required.
>>
>>
>>
>> #6 - Control plane memory is not an issue these days. To mitigate the
>> real issue this draft tries to solve a PE which
>>
>>        suffers from excessive number of VPN routes with given RD can
>> suppress installation of those routes to data plane
>>
>>        or locally drop it. Signalling it to the peer is practically not
>> needed and only causes more issues then it solves.
>>
>>
>>
>> Kind regards,
>>
>> Robert
>>
>>
>>
>> On Sat, Aug 20, 2022 at 3:48 AM Zhuangshunwan <zhuangshunwan=
>> 40huawei.com@dmarc.ietf.org> wrote:
>>
>> Hi Sue and WG,
>>
>>
>>
>> I support the WG adoption of this draft.
>>
>> The current draft has been actively discussed by the WG over the past
>> months, and all the comments raised in the IDR list have been addressed,
>> now it is a result of the joint efforts of the WG and worth continuing to
>> optimize it as a WG draft.
>>
>> The solution would help to quickly isolate a faulty VPN and avoid further
>> deterioration of the network operation status.
>>
>> I am unaware of other undisclosed IPR for this draft.
>>
>>
>>
>> Best Regards
>>
>> Shunwan
>>
>>
>>
>>
>>
>> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Susan Hares
>> *Sent:* Tuesday, August 16, 2022 11:56 PM
>> *To:* idr@ietf.org
>> *Subject:* [Idr] Adoption and IPR call for
>> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>>
>>
>>
>> This begins a 2 week WG Adoption call for
>> draft-wang-idr-vpn-prefix-orf-03.txt
>>
>> https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf/
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf/__;!!BhdT!ldABksoTX4ZcjR7ustBB-6Br7ALCA-0ovGEa4nQwptA-Ly5ULxnLlHqXUFgjtKPYCDfuwxIXRSI$>
>>
>>
>>
>> The authors believe that they have addressed the concerns raised in
>>
>> the previous 2 WG adoption calls.
>>
>>
>>
>> The WG should consider if:
>>
>>
>>
>> 1) The revised text answers the previous concerns regarding
>>
>> the scope of this draft?
>>
>>
>>
>> 2) Does the revised text provide a useful function for
>>
>> networks?
>>
>>
>>
>> 3) Are there any additional concerns regarding the new text?
>>
>>
>>
>> Each of the authors should send an IPR statement for
>>
>> this version of the draft.
>>
>>
>>
>> The adoption call was moved to 8/29 to 8/30 to allow questions
>>
>> to be asked at the IDR interim meeting on 8/29/2022 (10am – 12pm EDT).
>>
>>
>>
>> Cheers, Sue Hares
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!ldABksoTX4ZcjR7ustBB-6Br7ALCA-0ovGEa4nQwptA-Ly5ULxnLlHqXUFgjtKPYCDfunxv7nkg$>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>