[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
- To: <erosen at cisco.com>, "Susan Hares" <shares at nexthop.com>
- Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
- From: "Fang, Luyuan, ALABS" <luyuanfang at att.com>
- Date: Fri, 21 May 2004 18:51:36 -0500
- Cc: "Ash, Gerald R \(Jerry\), ALABS" <gash at att.com>, "Yakov Rekhter" <yakov at juniper.net>, <idr at ietf.org>
- List-archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
- List-help: <mailto:idr-request@ietf.org?subject=help>
- List-id: Inter-Domain Routing <idr.ietf.org>
- List-post: <mailto:idr@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
- Sender: idr-admin at ietf.org
- Thread-index: AcQ8R38ZeEUIpGJFScKig2hEwgaeBADQ6sGA
- Thread-topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Eric,
I focused on the fundamental issue of removing manual work in the last mail, may not be quite clear on the warning limit and reset limit. But I did mention that the "three level threshold" approach makes the prefix limit control to be proactive.
It is important to have the "three level threshold", here is my thought on this:
The max prefix for PE to stop sending is the 1st priority, it seems you and a few others agreed on this.
The warning limit is also important to be communicated and set at the CE from an operational perspective. The negotiation of the warning parameter from both sides, allows the a warning to be issued at the provider and the customer. As the provider and the customer agreed to increase the limit, the new limits can be negotiated while keeping the connection up. The warning limit will allow CE side operators to notice and fix the problems before the Stop limit is reached and the damage is done, this makes customer network management rather proactive than reactive. This is more important for the customer network than the provider network.
The reset/drop limit is needed, because that will provide the last safe guard if the CE did not STOP sending as the result of malfunctioning, etc. (One of the common types of malfunctioning is the sending of a full routing table or a major portion thereof to a neighbor by mistake.) This last threshold allows some "graceful space" between the STOP limit and the reset limit, and yet protects the PE and the provider network from overrunning the resource.
For PE, this is very important, to not relying on CE always behaving correctly. To CE, it is rather informational, CE cannot change this threshold on PE.
Do we need to signal this to CE or not? That's the point of our discussion. The signaling may allow the NOC to alter the reset limit signaled to the CE separate from the ignore limit.
This change can allow different types of errors to have different penalties based on the operational pattern of the CE. That gives the most flexibility for the operation staff to handle errors.
A one size fits all hammer doesn't give us the control as the 3 limits.
Thanks,
Luyuan
-----Original Message-----
From: Eric Rosen [mailto:erosen at cisco.com]
Sent: Monday, May 17, 2004 3:45 PM
To: Susan Hares
Cc: Fang, Luyuan, ALABS; Ash, Gerald R (Jerry), ALABS; Yakov Rekhter;
idr at ietf.org
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document
> Could you be specific on what other thresholds?
In draft-chavali terminology, I think Luyuan's argument supports the use of
the "maximum prefix limit" but not the "reset prefix limit" or the "warning
prefix limit".
Since the "maximum prefix limit" is essentially the same (I think) as the
"prefix limit" of draft-keyur, I don't think that Luyuan's argument provides
a basis for preferring draft-chavali.
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www1.ietf.org/mailman/listinfo/idr