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

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 20 Apr 2004 07:52:08 -0500

> We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt
> as an IDR WG document. Please send comments to the list. The deadline
> for comments is April 29, 2004.

This draft addresses an important issue, and proposes a reasonable approach to address the issue.  I support this becoming a WG document.

Jerry

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

---

From: Parantap Lahiri <[email-masked]>
Date: Tue, 20 Apr 2004 14:22:14 -0400

This draft proposes some reasonable approach to solve some existing issues. 

In VPN world the number of prefixes can slowly creep up and an elaborate
mechanism for warning, stop and reset could be helpful but in public SP
world in most of the cases the SP maintains a static prefix-list for each
customer. Usually the customer needs to contact the SP if they need to
modify that prefix-list. 

Typically though, the SP accepts any prefixes which are more specific to the
ones maintained in the prefix-list filter. The problem arises when the
customer accidentally de-aggregates their prefixes. And when that happens
depending on the block that got de-aggregated, the number prefix send by
customer could experience a sudden sizeable jump. In today's world, there is
a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session would
go down permanently if the max-prefix-limit is exceeded. It would take an
urgent operator intervention to bring it up again, of course the operator
would need to make sure the cause has been taken care off before bringing
the session up.

So if we want to use the draft approach to take care of this particular
scenario, a filtering mechanism depending on the specificity of a prefix
could become important. For, e.g., if a session hits the stop level, the
sender could resend all its prefixes after filtering out any prefix more
specific to /24 etc. Of course this specificity should be configurable.
However, if for example, /24 is chosen, it would ensure all the customer
prefixes are still globally routable, but some of their load-balancing
mechanism can get affected. So the price the customer pays for the mishap
gets less harsh.

On the other hand, the approach mentioned in the draft could be useful on
the BGP sessions used for peering with equivalent SP peers.

-Parantap

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ash,
Gerald R (Jerry), ALABS
Sent: Tuesday, April 20, 2004 8:52 AM
To: [email-masked]; Yakov Rekhter
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
document

> for comments is April 29, 2004.

This draft addresses an important issue, and proposes a reasonable approach
to address the issue.  I support this becoming a WG document.

Jerry

---

From: Parantap Lahiri <[email-masked]>
Date: Tue, 20 Apr 2004 14:22:14 -0400

-Parantap

-----Original Message-----

Jerry