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