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

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:37:40 -0400

Pekka and John:

The feature you describe here:

  >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.)

Is in the original draft: It is negotiated at initial OPEN and allowed
to change while connection (ORF/Dyn-Caps are options).

So, are you happy with the 3 limits: warning, ignore, disconnect?
Do you want these limits for all prefixes, a prefix length or
some specific prefix?

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Thursday, May 06, 2004 1:00 PM
To: Pekka Savola
Cc: [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document

At 3:04 PM +0300 5/5/04, Pekka Savola wrote:
...
>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.)

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

>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.)

Yes.

Regards,

--John

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

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 May 2004 07:45:59 +0300 (EEST)

> Do you want these limits for all prefixes, a prefix length or

I want the limits to be for all prefixes.  I don't see a real scenario
for anything else.

As I described, there are two things here:

 1) What's being done by the local routers.  They're configured with 
specific kinds of prefix limits.  Current prefix-limits in the 
implementations support at least the local warning, and the local 
reset.

 2) What's being signalled to the foreign routers.  As John described, 
there is *no* use of signalling reset limit to the peer, because reset 
limit is enforced by the local peer.

That leaves us with notifying of warning limit and stop limit only.  
Both could be useful, but I could live with just one as well.  The
preferable spec would be that these are sent when the session is being
opened, and only re-sent if the local administrator changes the
limits.  The foreign peer stores these values, and issues warnings at
their end (using a to-be-defined MIB, for example -- the same
what it does when prefix-limits are configured to warning locally), 
and for the stop limit, restricts the number of prefixes it sents when 
the number exceeds Adj-Ribs-out for the peer.

Again, disconnect limit doesn't need to be signalled, as the local
peer is going to disconnect the remote end based on the locally
configured disconnect limit in any case.

-- 
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, 12 May 2004 07:45:59 +0300 (EEST)