[GROW] draft-sa-grow-maxprefix - Problems with -02.txt text

["Susan Hares" <[e-mail]>]

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.