Subject: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document

From: Yakov Rekhter <[email-masked]>
Date: Sun, 02 May 2004 08:50:26 -0700

Folks,

We didn't get sufficient consensus to accept 
draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document. 

The authors of draft-chavali-bgp-prefixlimit-01.txt produced
a new version, draft-chavali-bgp-prefixlimit-02.txt, and would
like the IDR WG to accept this *new* version as an IDR WG document.

Please send comments to the list. The deadline for comments is 
May 17, 2004.

Yakov. 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 May 2004 15:04:11 +0300 (EEST)

> like the IDR WG to accept this *new* version as an IDR WG document.

I've no objections to this.

FWIW, below are some comments I wrote up when reviewing the new spec.

A high-level comment:
---------------------

The model seems to be so that when the receiving BGP speaker receives the
number of routes which exceed a warning, stop or reset limit, it sends a
message to inform the other router about exceeding this limit, raising a
warning, askit it to stop, or reset the session.

There is another way to specify this as well.  Each router sends the other,
_in advance_, when opening the BGP session, their prefix limits; these
values are stored per peer.  The sending router checks the length of its
adj-ribs-out for the peer whether it exceeds any of these limits, and raises
warnings, stops advertising, etc. as appropriate.  (In that model, no 
compliant router ever exceeds these limits, even temporarily.)

The main difference here appears to be that the currently specified model
requires the receiving BGP speaker to react _after_ the incident.  I.e., if
the neighbor accidentally advertises the whole internet (instead of e.g.,
100 prefixes), the damage has already been done, and most probably, the BGP
session has already been reset, because the receiving BGP speaker has 
to have prefix-limits in place in any case to ensure that neighbors 
will honour the limits.

So, IMHO that would argue for notifying the router about your limits in
advance.. and if the other router does not honor them, raise and alarm, shut
down the session, etc. on your own if needed.

If you buy the latter model, the error code 5 appears to be unnecessary.

(Both models allow changing the limit on the fly with dynamic capabilities,
I think.)

more specifics:
---------------

   The basic functionality proposed here is for the BGP speakers to
   exchange: "warning", "stop receiving" and "disconnect" based limits.

==> s/proposed/specified/
==> s/speakers to exchange/speaker to notify/

(there is no _exchange_: each peer just _notifies_ the each other of its
limits, end of story.)

These limits are exchanged
   during the initial exchange as "open capabilities", and via the
   dynamic capability exchange during the bgp connection.

==> s/exchanged/sent/
(the rest in this section are probably fine.)

  Meaning for each of the bitwise indicated capability fields above is
   as follows:

==> the following text and different codes are difficult to read.  Would it
be possible to indent these appropriately, put in subsection, or whatever
for better readability?

   Limit Indicator (1 octet):
                                                                                                                               
   This octet can be assigned a value of 0 or 1. A value of zero means
   that the sender SHOULD NOT raise any warning. A value of 1 means the
   warning indication is necessary and SHOULD be used by the sender when
   its route advertisement equals the number of sent routes. It has the
   same meaning in all the subcodes. However, in subcode 2 it can take a
   value of 1 only. The warning mechanisms are described in the
   operation section of this draft.

==> this appears to be useless.  There is no point in sending a warning
limit unless it's supposed to warn; the same about reset.  If this spec
hasn't been implemented already, I'd suggest making this all zero, and
requiring the warning request.  If it has been implemented, just require "1"
for the (right-most?) bit always, and the rest zero.

   warning prefix limit (4 octet):
                                                                                                                               
   Number of routes sent by the BGP sender. The value for this field is
   dependent on the maximum prefix limit and SHOULD be always less than
   it.

==> s/SHOULD/MUST/ ?

   maximum prefix limit (4 octet):
                                                                                                                               
   Number of routes sent by the sender BGP speaker. When this limit is
   hit by the advertising BGP speaker it stops the route advertisement.

==> (the same around subcode 2) -- this should be more clear what "stops the
route advertisement" means.  Withdraw all the prefixes?   Stops from
advertising any new prefixes, ...., ... ?

Note that stopping advertising new prefixes could be difficult to implement
(or so I might imagine).

   It MUST be noted here that this situation will never be encountered
   if adhered to the draft. In other words this happens only during
 
==> s/adhered to the draft/this memo is followed/

4.1 Exchanging the configured prefix limits
                                                                                                                               
   BGP speakers exchange the prefix limits as an optional capability
   parameter [BGP-CAP] as described in section 4.
                                                                                                                               
 [...]
                                                                                                                               
   In figure 1 both BGP speakers A and B exchange the prefix limits
   (defined in section 4) to indicate the support for this capability.

==> again, this needs to be clearer what is exchanged.  The dynamic
capability is probably exchanged.  The routers notify those which support
the capability of their prefix limits.  The notified routers may act on them
if they want.  The notified routers don't have to send you their prefix
limits (if they have them).
==> (similar later on in the section)

7. References

==> need to be split to normative and informative.

8. IANA Considerations
                                                                                                                               
   This document uses a new capability type for the support of prefix
   limits and the corresponding NOTIFICATION code along with the sub-
   codes for non-support. This must be assigned by IANA.

==> this section should be much more clearer on what should be assigned and
based on which which section of the document (e.g., possibly in a table
form).

10. Full Copyright Statement
                                                                                                                               
   Copyright (C) The Internet Society (2000).  All Rights Reserved.

==> a bit out of data year.

==> include the IPR boilerplate.

11. Author's Addresses:

==> s/'s/s'/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 May 2004 15:04:11 +0300 (EEST)

A high-level comment:
---------------------

more specifics:
---------------

==> s/exchanged/sent/

                                                                                                                               

                                                                                                                               

==> s/SHOULD/MUST/ ?

 

                                                                                                                               
 [...]

7. References

8. IANA Considerations

                                                                                                                               

11. Author's Addresses:

==> s/'s/s'/

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 6 May 2004 12:59:46 -0400

At 3:04 PM +0300 5/5/04, Pekka Savola wrote:
...
>A high-level comment:

Note that this is exactly what we've proposed in 
draft-keyur-prefixlimit-orf-00.txt.

>(Both models allow changing the limit on the fly with dynamic capabilities,

Yes.

Regards,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 6 May 2004 12:59:46 -0400

Yes.

Regards,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 6 May 2004 17:19:56 -0400

...
>>(Both models allow changing the limit on the fly with dynamic capabilities,

To clarify, what we propose in draft-keyur-prefixlimit-orf-00.txt 
allows changing the limit on the fly but uses ORFs rather than 
dynamic capabilities.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 6 May 2004 17:19:56 -0400

...

--John