Re: [GROW] draft-sa-grow-maxprefix - Problems with -02.txt text
Job Snijders <job@ntt.net> Tue, 24 September 2019 12:22 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 60B5712021D for <grow@ietfa.amsl.com>; Tue, 24 Sep 2019 05:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_NONE=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 Qudmh1xz7ouN for <grow@ietfa.amsl.com>; Tue, 24 Sep 2019 05:22:22 -0700 (PDT)
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (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 9E47A120096 for <grow@ietf.org>; Tue, 24 Sep 2019 05:22:21 -0700 (PDT)
Received: by mail-ed1-f53.google.com with SMTP id f20so1628521edv.8 for <grow@ietf.org>; Tue, 24 Sep 2019 05:22:21 -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=xPi3OLOrG8PQj4CqLyT97evFXo/h2IEVw8vx9XM4ukA=; b=RGrcHl2gvjkwWBI0I4VRnAY5R0RGkhU0j75TP2kyIKnZrXBvfvMwCpuY0bbTiwnyGH KvoKzBj+pnD9xnKXooraHBTjTwkBKhq3hKaJPNszt+bo/Pyv3J9ng8i2q3HoYuyvKb0g 5xtaLNDLNoKf0A4wEZ/ihAVdsSKpG7hpgUj6gmGrYYAf7Of4Cx72l8nSto5DalySUJ9b oy32CWzQB+P9UMTlFlaTruwfvdYqHdZMb73SYLYe4m/1Zzg/nx+hee4/ezjM4495HAY8 SrrwMb+ozWE5C4Efsd519zZzaqFGFtINTsronNa3AIWB9JkuNjgoXMkwMq7c+Ge3qFsN Ceqw==
X-Gm-Message-State: APjAAAWrdxbxKW2xhrN/0A1eTdgdk3UA1/dU+oYOjEx+ISleK2626XXP mZOtRUMtTxCnum4DMun6ScT97lBbIB4=
X-Google-Smtp-Source: APXvYqxAI5YEgE76Xaq0bI1p0teOQauxRo6h1P4ecQLSaBtcEjELQFN6odymBP6+mB5P2Bp/1mQMKQ==
X-Received: by 2002:a17:907:41db:: with SMTP id og19mr2149824ejb.307.1569327739665; Tue, 24 Sep 2019 05:22:19 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:8da9:ceb6:f357:829]) by smtp.gmail.com with ESMTPSA id a13sm194243ejj.23.2019.09.24.05.22.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Sep 2019 05:22:18 -0700 (PDT)
Date: Tue, 24 Sep 2019 14:22:17 +0200
From: Job Snijders <job@ntt.net>
To: Susan Hares <shares@ndzh.com>
Cc: grow@ietf.org
Message-ID: <20190924122217.GF10548@hanna.meerval.net>
References: <021901d562de$31241e10$936c5a30$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <021901d562de$31241e10$936c5a30$@ndzh.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/3MkWeYSD_xSYyVdbFx5cwSOKoHs>
Subject: Re: [GROW] draft-sa-grow-maxprefix - Problems with -02.txt text
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, 24 Sep 2019 12:22:25 -0000
Dear Susan, Thank you for your elaborate feedback. I think you are touching upon a lot things that can be improved, and I think you've implicitly also made a case that this document should be further developed in IDR rather than GROW. Thank you. We will incorporate your suggestions and re-submit as draft-sa-idr-maxprefix-00 Kind regards, Job & Melchior On Wed, Sep 04, 2019 at 01:04:11AM -0400, Susan Hares wrote: > Grow WG: > > > > I applaud the effort to further specify Maximum prefix > > (inbound, outbound) based on operator input. > > Operators know the appropriate limit sizes or > > operational mechanisms. > > > > However, this draft specifies not limits but > > BGP mechanisms. I suggested to the authors at IETF 105 > > that they review appropriate BGP Specifications (RFC4271 > > and the associated revisions) and BGP Yang model, and > > Then align the drafts with IDR specifications. > > > > However, I have not seen a revision of the draft that either: > > 1) aligns this text with the RFC4271, RFC4486, and RFC6608, or > > 2) Denotes this as input to the IDR WG for a draft. > > > > Therefore, I can only assume this document intends to be a standard > > that modifies RFC4271. Based on that assumption, this > > strongly urges a rewrite of all sections of this draft to > > align with the BGP base specifications prior to adoption. > > > > While I strongly believe in this effort to clarify and enhancement > > Maximum Prefix limits, the draft is not specific enough > > to be an appropriate standard for BGP. > > If this draft is to be an operational handbook, > > More comments on limits might be useful. > > > > Should the authors wish to collaborate, I will provide an > > alternate set of text based on my comments below > > for the BGP mechanisms. > > > > > > Susan Hares > > > > ---------------------------- > > > > Here are the problems: > > > > Problem 1: The draft does not indicate that it updates RFC4271 or RFC4486. > > > > However, it directly changes the way the "MAY" works in section 6.7 Cease. > > It provides standard language without a context of the RFC4271 section 6.7 > or > > the associated FSM (section 8) or the update error handling. > > > > The draft cannot change BGP Standards without being specific. > > If you are going to recommend changes to RFC4271, be specific. > > If you are going to recommend requirements so that IDR can change > RFC4271, be specific. > > This draft does neither one. Please adjust the draft. > > > > Problem 2: Section 2 - tries to replace the second paragraph of RFC4271 > without being > > as specific or stating that it replaces the paragraph. > > > Section 6.7 of RFC4271 > In the absence of any fatal errors (that are indicated in this > section), a BGP peer MAY choose, at any given time, to close its BGP > connection by sending the NOTIFICATION message with the Error Code > Cease. However, the Cease NOTIFICATION message MUST NOT be used when > a fatal error indicated by this section does exist. > > A BGP speaker MAY support the ability to impose a locally-configured, > upper bound on the number of address prefixes the speaker is willing > to accept from a neighbor. When the upper bound is reached, the > speaker, under control of local configuration, either (a)discards > new address prefixes from the neighbor (while maintaining the BGP > connection with the neighbor), or (b) terminates the BGP connection > with the neighbor. If the BGP speaker decides to terminate its BGP > connection with a neighbor because the number of address prefixes > received from the neighbor exceeds the locally-configured, upper > bound, then the speaker MUST send the neighbor a NOTIFICATION message > with the Error Code Cease. The speaker MAY also log this locally. > > > > Section 2.0 of draft-sa-grow-maxprefix states: > > > > An operator MAY configure a BGP speaker to terminate its BGP session > with a neighbor when the number of address prefixes received from > that neighbor exceeds a locally configured upper limit. The BGP > speaker then MUST send the neighbor a NOTIFICATION message with the > Error Code Cease and the Error Subcode "Threshold reached: Maximum > Number of Prefixes Received", and MAY support other actions. > Reporting when thresholds have been exceeded is an implementation > specific consideration, but SHOULD include methods such as Syslog > [RFC5424 <https://tools.ietf.org/html/rfc5424> ]. Inbound Maximum Prefix > Limits can be applied in two > distinct places in the conceptual model: before or after the > application of routing policy. > > Is this draft looking to change the words in RFC4271? > It seems as though the authors which to change RFC4271 want to change > RFC4271. The text is only really suggesting a change on what happens > during 3 types of upper bound are reached. > > The rest of the restatement of RFC4271 is less specific and > seems to change words without allowing for case a) in RFC4271. > In addition, "and MAY support other actions" in draft-sa-grow-maxprefix > is not an acceptable addition to RFC4271. The additions to > RFC4271 must contain enough specific information to provide a platform > for correct information texting. > > This text lacks the lacks the clarity of RFC4271 and makes > gratuitous changes. > > It only really needs to augment the first sentence: > > A BGP speaker MAY support the ability to impose a locally-configured, > upper bound on the number of address prefixes the speaker is willing > to accept from a neighbor. > > To the following: > > A BGP speaker MAY support the ability to impose a locally-configured, > upper bound on the number of address prefixes the speaker is willing to > accept from a neighbor (inbound maximum prefix limit) or send to a > neighbor > (outbound prefix limit). The limit on the prefixes accepted from a > neighbor can be before policy processing (Pre-Policy) or after policy > processing > (Post-Policy). Outbound prefix limits MUST be measured after policy since > the > Policy (even a policy of "send all") is run before determining what can > be sent. > > At the end of the paragraph, the text can be changed to: > If the BGP peer uses option b) where the limit causes a CEASE > Notification, then the > CEASE error codes should use the CEASE subcodes for > 1 Maximum Number of Prefixes Reached > 9 Maximum Number of Prefixes Reached (inbound, post-policy) > 10 Maximum Number of Prefixes Reached (outbound) > > > Problem 4: Section 2 introduction - lacks a link to the BGP FSM text > > This text does not show an understanding the link to the > AutomaticStop event. > > > > > See what RFC4271 states as (see page 71) > > One reason for an AutomaticStop event is: A BGP receives an UPDATE > messages with a number of prefixes for a given peer such that the > total prefixes received exceeds the maximum number of prefixes > configured. The local system automatically disconnects the peer. > > > > If you are going to define alternate mechanisms for the AutomaticStop > event in the > > BGP FSM, this text must be expanded to indicate the text for: > > a) Pre-Policy inbound maximum > > b) Post-Policy inbound maximum > > c) Outbound prefix maximum > > > > The text must be provided to provide these as example options for the > AutomaticStop event. > > > > Problem 5: Section 2.1 (Type A: Pre-Policy) can be tested by looking at > things on the wire. > > Section 2.2 (Post-Policy) cannot be tested by looking at things on > the wire. > > > > First of all RFC4271, carefully looks at things that can be observed on > the wire. > > If you really going to test something that is not on the wire, please > > specify a variable that a BGP Yang model can set a variable on. > > > > In fact, if you are wrapping this into one specification, then this > specification > > Should include suggested changes to the BGP Yang Model. > > > > Problem 6: Where to place Text from section 2.1 and 2.2 in RFC4271 > > The text can either go in section 9 and referenced in section 6, or > > or in section 6 and referenced in section 9. > > > > I recommend that this text go in section 9 of RFC4271 as these features > > > place new requirements on route processing. > > > > Problem 7: The following Text in section 3 is redundant if you use the text > suggestion above > > And RFC4486 (per existing updates to RFC4271). The entire text is > redundant - so either it goes in an > > accompanying application document or in reduced form in section 9.x of > RFC4271. > > > > An operator MAY configure a BGP speaker to terminate its BGP session > with a neighbor when the number of address prefixes to be advertised > to that neighbor exceeds a locally configured upper limit. The BGP > speaker then MUST send the neighbor a NOTIFICATION message with the > Error Code Cease and the Error Subcode "Threshold reached: Maximum > Number of Prefixes Send", and MAY support other actions. Reporting > when thresholds have been exceeded is an implementation specific > consideration, but SHOULD include methods such as Syslog [RFC5424 > <https://tools.ietf.org/html/rfc5424> ]. > By definition, Outbound Maximum Prefix Limits are Post-Policy. > > > > The Adj-RIBs-Out stores information selected by the local BGP speaker > for advertisement to its neighbors. The routing information stored > in the Adj-RIBs-Out will be carried in the local BGP speaker's UPDATE > messages and advertised to its neighbors Section > <https://tools.ietf.org/html/rfc4271#section-3.2> 3.2 [RFC4271]. The > Outbound Maximum Prefix Limit uses the number of NLRIs per Address > Family Identifier (AFI) per Subsequent Address Family Identifier > (SAFI), after application of the Export Policy, as input into its > threshold comparisons. For example, when an operator configures the > Outbound Maximum Prefix Limit for IPv4 Unicast to be 50 on a given > EBGP session, and were about to announce its 51st IPv4 Unicast NLRI > to the other BGP speaker as a result of the local export policy, the > session MUST be terminated. > > Outbound Maximum Prefix Limits are useful to help dampen the negative > effects of a misconfiguration in local policy. In many cases, it > would be more desirable to tear down a BGP session rather than > causing or propagating a route leak. > > > > Problem 8: Considerations for soft and hard limits > > > > This is really the indication of (a) or (b) in RFC4271. The text here > would be redundant. > > > > Problem 9: Security considerations section > > > > This section does not provide the appropriate depth of security to indicate > > why maximum prefix provides a tool for limiting attacks or errors to > > bring down networks. > > > > Problem 10: Redefining existing code problematic > > > > It is always problematic to redefine an existing code. It is better to > > use a new code. I strongly urge you to not do the following: > > > > This memo requests that IANA updates the name of subcode "Maximum > Number of Prefixes Reached" to "Threshold exceeded: Maximum Number of > Prefixes Received" in the "Cease NOTIFICATION message subcodes" > registry under the "Border Gateway Protocol (BGP) Parameters" group. > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow
- [GROW] draft-sa-grow-maxprefix - Problems with -0… Susan Hares
- Re: [GROW] draft-sa-grow-maxprefix - Problems wit… Job Snijders