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

Igor Malyushkin <gmalyushkin@gmail.com> Wed, 24 August 2022 19:00 UTC

Return-Path: <gmalyushkin@gmail.com>
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 41FE3C14F727 for <idr@ietfa.amsl.com>; Wed, 24 Aug 2022 12:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vcZUz01XZQnS for <idr@ietfa.amsl.com>; Wed, 24 Aug 2022 12:00:32 -0700 (PDT)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (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 36D82C15EE0F for <idr@ietf.org>; Wed, 24 Aug 2022 12:00:05 -0700 (PDT)
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-334dc616f86so484621827b3.8 for <idr@ietf.org>; Wed, 24 Aug 2022 12:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=ZjAuER769oZAtuP9e0VMeQzwu2HK9220Cxk7/XwZ78I=; b=j38vHu8esSZvbBSKPvlXUNcH/s5H9xvwCOWpoAHW3/eCqxSRHanUfhUY1YSwzn9m6D 9uAMMv0RIfaKnK4rdLG4amqAEekC1g016qv4oh485acRLY4sEN9RzXaZSUGNTOU6q5bQ 3WOxrFFTRn/TA7yAUTb0yPsZyuWWc4mq3wo0nZq1qeAUAY3LZhs2DGAIRDsRw538yaBb iCCRerau2CSMgbr4A8FuXPYPiRO/s1hyN1pxziP/UmNo7WuutyUWaXDtINaCaBcsx3aQ pg6UBOFoiD1CKV0izUAyLWsU+6LAXdHlHLeLOPypNlXylFH/TyOvI79Jy1MjlL979eQ/ tagA==
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=ZjAuER769oZAtuP9e0VMeQzwu2HK9220Cxk7/XwZ78I=; b=jWUCG/Bj9dJ/qEtoLSD6gTbFuC3HMDhYbx2PRDiKpEEGJgLEsqFod0mYZNieJh9I92 3TYm1V8uW92pTwLM+JGPQLcaNrickue/BY8b2sRJz1nOPJu2HT7wYm6AK9zKeSId9amU tQXIDo0pXuc55gpAlW+KbPbp410iYo8z+a+rBiDCxpurewOAU0KbHHQu9/mqe9r72EBJ BZdIR8oLvLNxrtdeHevvAriP2i2MdAwdqK6lo9KgmRYE9YZ6spjA0nb4CsKmrwmNorWu UNoVTR4zwkMp1zVR1u7cjSX5XtywuiOkh1wVZzWO2KvQiGZei4RHYgw05Wdgmt/Ta7Za Zkvg==
X-Gm-Message-State: ACgBeo1z+r5n3SkWUi3sP+mJ0SgA2NpGUsqwRsUSQ+WK02BZnZ8VzzNR oZKwSG4DS8HGhflNc85ViPWSXsKLivViQpc+4OA=
X-Google-Smtp-Source: AA6agR5S/WuxEHHwCaLcIAik9hmHWQFjviWp3NhxPYjFtsNQOBeQM0ZL5/bgyk6QqaxWJXStBVVD4UBXFIgqUTdNe1o=
X-Received: by 2002:a25:5f04:0:b0:671:5f9b:8100 with SMTP id t4-20020a255f04000000b006715f9b8100mr491483ybb.548.1661367603912; Wed, 24 Aug 2022 12:00:03 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR08MB487262F752C8777A1B9698EFB36B9@BYAPR08MB4872.namprd08.prod.outlook.com> <d9e07ea96dd64ea081ba763941a22b17@huawei.com> <6f9c478a2ef745818e3ef3d713218dae@huawei.com>
In-Reply-To: <6f9c478a2ef745818e3ef3d713218dae@huawei.com>
From: Igor Malyushkin <gmalyushkin@gmail.com>
Date: Wed, 24 Aug 2022 20:59:51 +0200
Message-ID: <CAEfhRry4zigpqp3qLzfRmvGvTv-+CygixENWLFaNV7_fKSw49Q@mail.gmail.com>
To: "Wanghaibo (Rainsword)" <rainsword.wang=40huawei.com@dmarc.ietf.org>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dfad3f05e7014992"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8f6bphPTjrxHRvTguu_oolyPNSo>
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: Wed, 24 Aug 2022 19:00:33 -0000

Hi Haibo,

2) It is unpractical to set the quota value for <RT>, or <RT, PE> under
VRF, because RT can't uniquely distinguish one VRF on one PE.
What if a VRF has several RDs for its routes? RFC4364 and RFC4659 don't
restrict this behavior and even more, it explicitly describes it. So, RD
also can't uniquely distinguish one VRF. Looks like we need a different
marker for all routes belonging to the same source VRF. Say, VPN ID
community or something like that.


ср, 24 авг. 2022 г. в 18:26, Wanghaibo (Rainsword) <rainsword.wang=
40huawei.com@dmarc.ietf.org>:

> Hi Sue and WG,
>
>
>
> I support this adoption.
>
> This draft proposes the mechanism to control the overflow of VPN routes
> within one VRF from influencing other VPNs on the same device
> automatically.
>
>
>
> The updated contents have accommodated the suggestions and addressed the
> comments raised within the WG discussions. Some additional concerns can be
> addressed after the adoption.
>
>
>
> I am not aware of any undisclosed IPR to this draft.
>
>
>
> To make the actual progress of this draft, we should avoid to discuss the
> solved points back and forth. For example, RTC mechanism is not suitable
> for the scenarios that described in this adoption draft, because:
>
> 1) RTC has no any automatic detection mechanism to determine which RT
> should be withdrawn now.
>
> 2) It is unpractical to set the quota value for <RT>, or <RT, PE> under
> VRF, because RT can't uniquely distinguish one VRF on one PE.
>
> 3) It is dangerous to propagate the RT based filter rule unconditionally
> in the intra-domain or inter-domain wide, as that done in current RTC
> mechanism.
>
>
>
> The conclusion, RTC is not the right direction to accomplish the goal.
>
>
>
> Regards,
>
> Haibo
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org <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
>