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
