I second Jerry, Mo, and Sue for supporting
draft-chavali-bgp-prefixlimit-02.txt to become WG document.
This draft presented the "three level threshold" approach (started
from first version presented in IETF 58) which makes the prefix limit
control to be proactive instead of passive as it is today. This can
help the providers to minimize service interruption, lower operational
cost and complexity.
In the current implementation, the prefix limit is only configured on
the BGP receiver (e.g., provider edge router), the BGP speaker (e.g.
CPE) does not have any control. Some implementation has warning
threshold option. When warning limit is reached, the trap will only
show up on the provider side, the operator has to contact the customer
by phone or through some messaging systems. When the drop limit is
reached, provider edge router would drop the session. (Some
implementation may drop routes which is over the limit from provider
side instead of drop session). The operator has to work with the
customer to reset the sessions when problems in the customer being
fixed. This involves a lot of manual work. In addition, provider have
to prove that the session drop was not due to network failure but the
customer violated the prefix limit, etc... Being on the network design
side, we hear a lot of complains from the operation folks on using the
prefix limit feature for customer connections.
Due to the intensive work involved, operators often simply not to use
the prefix limit feature for connecting customers, especially for
Internet services connections. But with network based MPLS/BGP VPNs
deployed in recent years, the router resource management became such a
critical issue, operators might be forced to use the prefix limit on
VPN customer sessions in order to protect the network resources,
especially the Provider Edge routers if the platforms have serious
scaling issues.
With the three level threshold and prefix limit exchange mechanism
proposed in this draft, the CPE gets the same three level thresholds
as set by Provider edge, the key is that CPE will STOP sending routes
when limits are reached, and the customer will the problems in his
network, no session drop nor route drop by the provider. Of course, if
the CPE does not function correctly and keep sending routes, there is
still the last level threshold provides the safe guard - drop (or
reset) the session by the provider.
This draft described the approach meets the operator's needs of
improving service quality, lowering the operation cost and complexity.
Luyuan
-----Original Message-----
From: idr-admin@ietf.org [mailto:idr-admin@ietf.org]On Behalf Of Ash,
Gerald R (Jerry), ALABS
Sent: Wednesday, May 12, 2004 8:50 AM
To: Yakov Rekhter; idr@ietf.org
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document
Those who were in favor of accepting
draft-chavali-bgp-prefixlimit-01.txt
as an IDR WG document need to say whether they are in
favor of accepting draft-chavali-bgp-prefixlimit-02.txt
as an IDR WG document.
Yes, I support this becoming a WG document. This is a useful
operational mechanism, wherein customers receive a warning on the
prefix-limit condition and can take action. This draft proposes a
reasonable approach to address the issue.
Jerry
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr