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 > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
