[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Write a cron job that sends them email.  Sheesh.

Tony


On May 14, 2004, at 3:08 PM, Robert Raszuk wrote:
Tony,

Just for the record I have pure IPv4 nationwide ISP who requested max-prefix "drop excess" action and has nothing to do with 2547 what so ever.

Notifying his own domestic customer that some routes (for example due to mistaken redistribution of full table) are being discarded was just an optional request.

One option is just to call the guys on the phone, send them a mail or send them an ORF msg in an automated way ahead of time. Dropping the session option was not acceptable as their entire domestic connectivity would be cut out.

I think that the max-prefix ORF Type is simple and harmless enough that we should proceed with forward - at least as an IDR WG item. Even if all the recipient would do with this information would be to have this available in the syslog as soon as the threshold is crossed would be an improvement to today's model of operation.

R.


> Tony Li wrote:
Isn't this just a band-aid to cover up the fundamental architectural flaw of mis-using BGP for 2547? If the CPE wasn't doing 2547, then it wouldn't be injecting routes, you'd have it statically routed and you wouldn't have to worry about what your customer was doing to you. Deploying 2547 in the first place elevates each and every customer to having the same kind of care and feeding that providers give each other, without the full time technical networking staff on the other side. Limiting their prefixes in number is one constraint that you're applying to them, but it cannot be all. Will you also flap dampen their prefixes? Do you advertise your flap parameters to them too?
Let's not turn BGP into our UNI please.
Tony
On May 14, 2004, at 11:56 AM, Fang, Luyuan, ALABS wrote:
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

_______________________________________________
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