Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix

Job Snijders <job@ntt.net> Fri, 26 July 2019 14:50 UTC

Return-Path: <job@instituut.net>
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 3C4FB120112 for <grow@ietfa.amsl.com>; Fri, 26 Jul 2019 07:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 qMmSlk9gS8yI for <grow@ietfa.amsl.com>; Fri, 26 Jul 2019 07:50:05 -0700 (PDT)
Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE41D120143 for <grow@ietf.org>; Fri, 26 Jul 2019 07:49:59 -0700 (PDT)
Received: by mail-qt1-f180.google.com with SMTP id h18so52836963qtm.9 for <grow@ietf.org>; Fri, 26 Jul 2019 07:49:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bEK6DFcvMCIu8hejMZjr/P4Ur38DXvNJpRGBq4iqaFA=; b=K1CkMjoeqxkEfTG95nfxdJ0jzBvt0DwCV7uSQtDNVLMzj8z3B/z8Yin/8RGSMNgRX/ YRyAhQWfGfs4Vlin9aN1uWhwBl5p9BxlzAp7MitpBWnM1YK1DTKlX6N1Ss42A6INubiz j4KhaME+BRAzEkDBTq9vwEhJC9Ah0LtQV/ygRGQiARzJrsICoELsZiWdOjML/gee5rrO 85snJRhtgW+JCmm9BkQVTLmhyxl98UFug7oYNaebBvWaLEUw2BxybnO07rh0kygMhFhV fUSfGblxMZjrXTnooA8wNa1H+D5bshrfFTf2cPBezORaqhLT4TUodze9nBMS02UkZ0Yr wyPg==
X-Gm-Message-State: APjAAAVDd+uTJS/SRezOBuqiDTe7VHgqf9++DCkW0ZRCpolPh5m1h98s siAt9GW2C220o/ixAJmKZP2Wx+aFlqA=
X-Google-Smtp-Source: APXvYqx8jIsRVtNRr7Tpx881d0AgQ9CSIM4PUA7DPdzai6oqCl6KSqe0D09YsaKBL1Zaryg1EsHG4Q==
X-Received: by 2002:ac8:1887:: with SMTP id s7mr66805501qtj.220.1564152598323; Fri, 26 Jul 2019 07:49:58 -0700 (PDT)
Received: from vurt.meerval.net (dhcp-995b.meeting.ietf.org. [31.133.153.91]) by smtp.gmail.com with ESMTPSA id g2sm21392184qkm.31.2019.07.26.07.49.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Jul 2019 07:49:57 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id d659a29c; Fri, 26 Jul 2019 14:49:55 +0000 (UTC)
Date: Fri, 26 Jul 2019 14:49:55 +0000
From: Job Snijders <job@ntt.net>
To: Robert Raszuk <robert@raszuk.net>
Cc: Melchior Aelmans <melchior@aelmans.eu>, grow@ietf.org
Message-ID: <20190726144955.GG81521@vurt.meerval.net>
References: <E4128E49-2CA1-4B2A-AB62-B60D4A3C4DF0@aelmans.eu> <CAOj+MMFNSLeP6kpxUbXGv7taNDAGdUO2wbjaPBpfrP6zzgSDQg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOj+MMFNSLeP6kpxUbXGv7taNDAGdUO2wbjaPBpfrP6zzgSDQg@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/49cP_OBePJuq8rrMAnqwlmj9BlI>
Subject: Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix
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: Fri, 26 Jul 2019 14:50:06 -0000

Dear Robert,

Thank you for your questions.

On Thu, Jul 25, 2019 at 02:43:38PM +0200, Robert Raszuk wrote:
> I would like to raise three points in respect to this draft:
> 
> Point 1:
> 
> The topic of outbound prefix limit is not new :) It has been discussed
> number of times within vendors and between vendors. But one
> requirement when we are talking about outbound prefix limit is which
> prefixes should be sent first - which are more important then others -
> so prefix prioritization in update generation and update scheduling
> comes up. Are we sure that this is not going to happen here ? Sure not
> in this draft, but once you build the road emergency vehicles and
> regular vehicles will try to use it. And while outbound prefix limit
> looks innocent the moment we start to ask for prioritizing prefixes
> some bgp implementations may have a bit of hard time.

We do not consider it a requirement to provide any guidance on which
prefixes should be sent first. Another draft can attempt to provide
guidance, or vendors can stick to their current approaches. You'll
notice from the draft that once the limit is reached a CEASE
Notification is sent; so I am not sure if the priority truly matters in
context of tearing down the session.

> Point 2:
> 
> The draft is still silent on the question I posted to the list
> regarding this idea in respect to decision which limit is more
> important ? Locally configured outbound limit or pushed by prefix
> limit ORF peers inbound limit ? What should be the action of the
> sender when those two numbers are not equal ? I think this must be
> precisely spelled out here.

Can you clarify what you mean with "pushed by prefix limit ORF peers
inbound limit"? As it currently stands it doesn't seem like
draft-keyur-idr-bgp-prefix-limit-orf is making a lot of head-way, so it
doesn't seem like there is a deployed mechanism we need to take into
consideration.

However, if I have to choose, I think I would prioritze the locally
configured limit as one could argue that local configuration supersede
instructions received from remote.

If you have specific suggestions what text and considerations should be
added to the draft I would welcome that.

> Point 3:
> 
> For inbound prefix limit the position if this should be pre or post
> policy should be IMHO a local configuration decision. See if I decide
> to keep full table in my Adj_RIB_In maybe just for BMP use no spec
> should prevent that.  Maybe it would be worth to add this explicitly
> to the draft in addition to listing those two measurement insertion
> locations :)

I agree that operators locally configure these limits and they
themselves choose to use no limits, pre-, post-, or a combination of
pre- + post- policy limits.

This Internet-Draft seeks to document that both exist, and formulate
things in such a way that when a vendor claims compliance with
draft-sa-grow-maxprefix, they indicate to support all of outbound,
pre-policy inbound, and post-policy inbound. A vendor could also
indicate they only have support for "draft-sa-grow-maxprefix section 2.2
type B", or only "type A".

My recommendation to BGP implementers would be to implement all three
types of prefix limits. My recommendation to operators is to configure
both pre-policy and post-policy limits, as each limit has different
advantages in context of Internet routing.

Kind regards,

Job