IETF Logo Mail Archive

Re: [GROW] Prefix limit ORF

"Aliaksei Sheshka" <afpd@yandex.ru> Tue, 26 March 2019 18:27 UTC

Return-Path: <afpd@yandex.ru>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3467F1208CB for <grow@ietfa.amsl.com>; Tue, 26 Mar 2019 11:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_RP_RNBL=1.31, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru
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 z9ruviKa_rPj for <grow@ietfa.amsl.com>; Tue, 26 Mar 2019 11:27:05 -0700 (PDT)
Received: from forward104j.mail.yandex.net (forward104j.mail.yandex.net [5.45.198.247]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9A11208A5 for <grow@ietf.org>; Tue, 26 Mar 2019 11:27:05 -0700 (PDT)
Received: from mxback4j.mail.yandex.net (mxback4j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10d]) by forward104j.mail.yandex.net (Yandex) with ESMTP id 277D24A3560; Tue, 26 Mar 2019 21:27:02 +0300 (MSK)
Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback4j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 5CVm2rE9dQ-R1ViBSo4; Tue, 26 Mar 2019 21:27:02 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1553624822; bh=/Z5yKhFeo39BEDkOwqH/J626h71WRhMrvXNuhrv9Dwc=; h=In-Reply-To:Subject:Cc:To:From:References:Date:Message-ID; b=hjv3YTe4aKVhOHtfZrPBxfjiYplE1e/VQe6v1xjPD8yjFhZnTXEC7CTn+8mgbIitF fdTND0iqdd6Akp9r/RfZx7+gGd19DQB0CvesWIkGYha+yjd1Rr6eBQqA/rV4UMl+ag niMQpUEqmF6Z01k2a1YOER7YVyQui9kt2LgVXjeQ=
Authentication-Results: mxback4j.mail.yandex.net; dkim=pass header.i=@yandex.ru
Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id RUkLh5ZCkc-R0te0jq8; Tue, 26 Mar 2019 21:27:00 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present)
Date: Tue, 26 Mar 2019 14:26:56 -0400
From: Aliaksei Sheshka <afpd@yandex.ru>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: "grow@ietf.org" <grow@ietf.org>
Message-ID: <20190326142656.1c21c6d6@host-m>
In-Reply-To: <D8F9A493-D343-4AFD-96DF-3F702BF79597@juniper.net>
References: <D8F9A493-D343-4AFD-96DF-3F702BF79597@juniper.net>
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/bu3D-ElIUOESHO6-J8S0bx-umb8>
Subject: Re: [GROW] Prefix limit ORF
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 18:27:15 -0000

On Tue, 26 Mar 2019 15:59:07 +0000
John Scudder <jgs=40juniper.net@dmarc.ietf.org> wrote:

> Apropos Job’s talk just now —
> 
> draft-keyur-idr-bgp-prefix-limit-orf-03
> https://tools.ietf.org/html/draft-keyur-idr-bgp-prefix-limit-orf-03
> 

 I fail to see how such approach solves anything.
According the draft max-pref is send through the same channel
as prefixes themselves. Why should one trust that? On other side,
if there was kind of RPKI object which ties ASN+AS-SET+maxpref
what would be a different story, since that would out-of-band
verification.

v2.23.0 | Report a Bug | By Email