Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

Jeffrey Haas <jhaas@pfrc.org> Mon, 21 February 2022 15:52 UTC

Return-Path: <jhaas@pfrc.org>
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 BE64A3A1178 for <idr@ietfa.amsl.com>; Mon, 21 Feb 2022 07:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpOIV_awNEEy for <idr@ietfa.amsl.com>; Mon, 21 Feb 2022 07:52:35 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6263A0DF9 for <idr@ietf.org>; Mon, 21 Feb 2022 07:52:35 -0800 (PST)
Received: from smtpclient.apple (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id E48401E341; Mon, 21 Feb 2022 10:52:33 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_71F8399A-155D-4C26-BDFC-145131A7C4DB"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <00d801d819c4$39f40f10$addc2d30$@ndzh.com>
Date: Mon, 21 Feb 2022 10:52:33 -0500
Cc: idr@ietf.org
Message-Id: <78735078-A870-4A68-AB05-498E6EA3DDD2@pfrc.org>
References: <00d801d819c4$39f40f10$addc2d30$@ndzh.com>
To: Sue Hares <shares@ndzh.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9RiwqpJgrQAMZbucTfzN-vqLQ-w>
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 21 Feb 2022 15:52:40 -0000

[Speaking as an individual contributor.]

Sue,

I do not support adoption of this draft.

After various discussions about the scope of the feature the authors seem to intend that:
- It address exhaustion by a Provider Edge device of RIB (and subsequently FIB) resources.
- Part of the concern is BGP messaging load on the receiving PE.
- This can be mitigated by causing remote drop of some portion of impactful routes.

The proposal has the issues that it:
- Will require additional per-route per-VRF counter state (potentially useful, somewhat expensive to implement)
- Does not provide an algorithm to determine drop, meaning no consistent local implementation of the feature.
- Does not address edge conditions wherein multiple classes of routes may be eligible for drop
- Will impose additional load on upstream BGP devices such as route reflectors to implement the filters
- Cannot guarantee prompt mitigation of the issues of concern.  Local filtering will be required as a mitigation during ORF installation at the upstream device.
- Installation of the ORF will generate additional messages for the withdraw messaging.

Much of the conversation about local PE behaviors amounts to, "I'll know it when I see it".  Implementation choice may be reasonable, but is too vague for the local end of a standard.

Discussion of this feature has resulted in the specification improving its clarity, but I don't foresee the above points converging across the disagreeing parties.

My recommendation is that if the authors wish to progress this proposal that they make it Experimental, request a First Come, First Served ORF code point from IANA, and take the draft to the Independent Submissions Editor track.

-- Jeff


> On Feb 4, 2022, at 7:39 AM, Susan Hares <shares@ndzh.com> wrote:
> 
> Resending the adoption call – with the appropriate header 
>  
> From: Idr [mailto:idr-bounces@ietf.org <mailto:idr-bounces@ietf.org>] On Behalf Of Susan Hares
> Sent: Friday, February 4, 2022 7:33 AM
> To: idr@ietf.org <mailto:idr@ietf.org>
> Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to 2/18/2022)
>  
> This begins a 2 week WG adoption call  for 
> draft-wang-idr-vpn-prefix-orf-00.txt 
> https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf <https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf>. 
>  
> In your discussion on adoption, please consider the following questions: 
>  
> 1) Does this draft describe problems existing in networks today? 
>  
> 2) Does the solution describe address these problems? 
> The solution has both a general solution and BGP encodings. 
>  
> 3) Would the solution be useful in networks today? 
>  
> Thank you, Susan Hares 
> <Untitled attachment 00214.txt>_______________________________________________
> Idr mailing list
> Idr@ietf.org <mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>