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

Robert Raszuk <robert@raszuk.net> Sat, 20 August 2022 08:28 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4635AC14CE36 for <idr@ietfa.amsl.com>; Sat, 20 Aug 2022 01:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BcGIedhqXlv for <idr@ietfa.amsl.com>; Sat, 20 Aug 2022 01:28:17 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014D5C152573 for <idr@ietf.org>; Sat, 20 Aug 2022 01:28:16 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id q2so5960075edb.6 for <idr@ietf.org>; Sat, 20 Aug 2022 01:28:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=QLff8bAZpnOgqMnpGD2TSPD3WCyzV1q7L43i5OdI/94=; b=aJIRSNJnG+qXup3yaRdOM06qpW2Vk3AtPn0VxXEGg1Hn1yejGxk24U2lfiQnPPK0cl WougSum6AS+xJIPAZIMAB2sqkFEoqG8tgToX4U1yyw6NtnhPv1sOPzR6ECJMlu6+xsI+ WF66H2imRCE1IxagbzQa7ekNFXwXvWxA5PF9gKizpmdleB4irYPKFFy7iGizRpKRoFNr JXXbwKP7y1KWRlGmuRnRe/AwFmQDi6wQOnS0OcbKkUiS5EDkUSpFA8XqlRPLSCWA33ri JPI0SIiL8koo/AdDR+9na5wS1Ukn+4R6iJI5ArcvLMRxK2ra+6lomulrcbbm9sgYFxQo Emrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=QLff8bAZpnOgqMnpGD2TSPD3WCyzV1q7L43i5OdI/94=; b=h7HtWpmfjm1X+Jf1tc7i11ofp4fzX5agzck/QEbFrOzCZdHqYAYd/1TcpG8+NGAb33 dSpYvaZfdVjsoyI64sry+stFU29bBbMqZMVC7lABcC3Mi8/N77xpqedey0VTaCrjeAtS eff9nb9mwyftL5U7zu7437xNOFd5V9D0v4JlRGfmCjP3duvLu0AgfQuZ1mAhJfg2Se7z HhIf8kHzExnPncZv/xC1fhHGfleLJ6isf2e/jBdXltCg0micl+thkhFYYt7cqfJkeB4+ QNcWe+hOeNF3PVN3iFPvcIYvmXcWqYZVOC/6WbUgXybJwCv5l7okGn5DajkaoGyEzLkW vH0w==
X-Gm-Message-State: ACgBeo3AeGjCcIddLFkWR6sX+SsP1GrUlggFBCmKII9s5tVlGHDGjw1T uaO2yUGM5MIU9WF+HheNOWWmT6jpbBUCtfTpXVW7fg==
X-Google-Smtp-Source: AA6agR4PXhwlOLaLlflVSoOsD/LmiHcAJHPgLwL2KrjRmqeZgndu8SV6XFNOhnY9KCZUxKVQAhLIV2fSaMg9ZGJLSBc=
X-Received: by 2002:a05:6402:5508:b0:43a:896e:8edd with SMTP id fi8-20020a056402550800b0043a896e8eddmr8708303edb.203.1660984094569; Sat, 20 Aug 2022 01:28:14 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR08MB487262F752C8777A1B9698EFB36B9@BYAPR08MB4872.namprd08.prod.outlook.com> <d9e07ea96dd64ea081ba763941a22b17@huawei.com>
In-Reply-To: <d9e07ea96dd64ea081ba763941a22b17@huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 20 Aug 2022 10:28:03 +0200
Message-ID: <CAOj+MMG=JH=RUtxbmuLsTsTe73+aT9PkqMLpmMbLi-O06inLaQ@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Cc: "idr@ietf.org" <idr@ietf.org>, Zhuangshunwan <zhuangshunwan=40huawei.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ef4fec05e6a7fed9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bnMjryaQEkKXJATN0z8qSPjL3AY>
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Aug 2022 08:28:21 -0000

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/
>
>
>
> 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
>