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

From: Yakov Rekhter <[email-masked]>
Date: Tue, 11 May 2004 19:35:54 -0700

Folks,

Given the current discussion on the mailing list, the deadline
for comments on accepting draft-chavali-bgp-prefixlimit-02.txt
as an IDR WG document is extended to May 24, 2004.

This way May 24 is the deadline for comments on the following:

1. whether to take signalled prefix limit as a WG item

2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR
   WG document

3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR
   WG document

In your e-mails please clearly indicate your preferences. Providing
rationale for your preferences would be extremely useful as well.

Yakov.

P.S If folks feel that the deadline should be extended beyond
May 24, please say so.

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 12 May 2004 07:49:36 -0500

> 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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 12 May 2004 07:49:36 -0500

Jerry

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 14 May 2004 11:15:00 -0400

Enrico:
 
Thank you for your comments.  
Yakov and I appreciate the input.
 
Could you let me know if you are:
a) vendor  b) network operator or
c) valued researcher/expert 
or d) other?
 
Sue 

-----Original Message-----
From: Enrico Salazar [mailto:[email-masked]]
Sent: Wednesday, May 12, 2004 9:49 PM
To: Yakov Rekhter; [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document

I object to taking signalled prefix limit, as I think that the existing mechanisms are sufficient to handle real-life scenarios (see
Pekka's e-mail).
 
If there is an agreement that there are real-life scenarios that
require signalled prefix limit, then I would be in favor of accepting
draft-keyur-prefixlimit-orf-00.txt.
 
I object accepting draft-chavali-bgp-prefixlimit-02.txt.
 
   Enrico

Yakov Rekhter <[email-masked]> wrote:

Folks,

Yakov.

  _____  

Do you Yahoo!?
Yahoo! Movies - Buy advance  <http://movies.yahoo.com/showtimes/movie?mid=1808405861> tickets for 'Shrek 2'

---

From: "Fang, Luyuan, ALABS" <[email-masked]>
Date: Fri, 14 May 2004 13:56:41 -0500

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: [email-masked] [mailto:[email-masked]]On Behalf Of Ash,
Gerald R (Jerry), ALABS
Sent: Wednesday, May 12, 2004 8:50 AM
To: Yakov Rekhter; [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document

Jerry

---

From: "Fang, Luyuan, ALABS" <[email-masked]>
Date: Fri, 14 May 2004 17:25:23 -0500

I do not want to go into the discussion of BGP should be used for 2547 or not. It is beyond this subject. But I want to say that something has to be used if we want to provide 2547 kind of network based VPN, whether it is BGP, or other existing protocols or create some new protocols, there is no free lunch. Perfect or not, 2547 VPN services are highly on demand by customers, and good revenue sources for providers. The fact is that it is there, in most provider networks worldwide.

If we only want to stay where we were as many years ago, there were many things we did not need to worry about...

The prefix limit needs largely come from box scaling issues. I'd think focusing on getting the routers more powerful, efficient, and capable would be rather helpful. It is providers' job to provide as many enhanced services as possible to their customers, it is vendors' job to make boxes better each year. Customers, providers, and vendors all benefit from the continues evolution/improvement, right?

Luyuan

-----Original Message-----
From: Tony Li [mailto:[email-masked]]
Sent: Friday, May 14, 2004 5:09 PM
To: Fang, Luyuan, ALABS
Cc: Ash, Gerald R (Jerry), ALABS; Yakov Rekhter; [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document

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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 17 May 2004 13:57:29 -0400

Eric:

Could you clarify for me a few things in
your last paragraph

"I don't see the argument  for dynamically learning multiple threshold levels
from a peer.  Especially as there  are no real semantics associated with the
other thresholds. "

Could you be specific on what other thresholds?

Sue

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Monday, May 17, 2004 1:01 PM
To: Fang, Luyuan, ALABS
Cc: Ash, Gerald R (Jerry), ALABS; Yakov Rekhter; [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document 

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

This suggests that it is useful for  a BGP speaker to know that a given peer
will only be  able to receive n prefixes.  In that  case, it certainly makes
sense for  the value  n to be  learned dynamically.   Both of the  drafts in
question support that functionality. 

I don't see the argument  for dynamically learning multiple threshold levels
from a peer.  Especially as there  are no real semantics associated with the
other thresholds.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 18 May 2004 06:47:31 -0400

Eric:

Thanks for clarifying that point.

Sue

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Monday, May 17, 2004 3:45 PM
To: Susan Hares
Cc: Fang, Luyuan, ALABS; Ash, Gerald R (Jerry), ALABS; Yakov Rekhter;
[email-masked]

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 18 May 2004 06:47:31 -0400

Eric:

Sue

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Monday, May 17, 2004 3:45 PM
To: Susan Hares
Cc: Fang, Luyuan, ALABS; Ash, Gerald R (Jerry), ALABS; Yakov Rekhter;
[email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 18 May 2004 07:01:27 -0400

Kurtis: 

<wg chair hat on> 
All votes are welcomed and answer
the standards question Yakov posed 
earlier. 

Not all votes indicated what will be
deployed in networks or how. 

In our past email discussions, there have
been many threads about making sure each
new feature in bgp is really needed
for operations of networks. 

<wg chair hat off> 

<personal hat on> 
Running code and rough consensus for IETF
usually means these questions are appropriate. 
Yes, I personally care what gets deployed and
that network operators get the tools they need to run 
networks.   I've worked on operator forums
(NANOG, etc) for over 15 years.  
<personal hat off> 

Sue

-----Original Message-----
From: Kurt Erik Lindqvist [mailto:[email-masked]]
Sent: Monday, May 17, 2004 10:38 AM
To: Susan Hares
Cc: Yakov Rekhter; [email-masked]; Enrico Salazar
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document

Why do you keep asking this? We are here as individuals - right? Or is 
there different value for the votes if you are one or the other?

- - kurtis -

On 2004-05-14, at 17.15, Susan Hares wrote:

> I object to taking signalled prefix limit, as I think that the 
> existing mechanisms are sufficient to handle real-life scenarios (see
> Pekka's e-mail).
>  
> Yahoo! Movies - Buy advance tickets for 'Shrek 2'

---

From: "Fang, Luyuan, ALABS" <[email-masked]>
Date: Fri, 21 May 2004 18:51:36 -0500

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:[email-masked]]
Sent: Monday, May 17, 2004 3:45 PM
To: Susan Hares
Cc: Fang, Luyuan, ALABS; Ash, Gerald R (Jerry), ALABS; Yakov Rekhter;
[email-masked]

---

From: "Fang, Luyuan, ALABS" <[email-masked]>
Date: Fri, 21 May 2004 18:51:36 -0500

Eric,

Thanks,
Luyuan

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Monday, May 17, 2004 3:45 PM
To: Susan Hares
Cc: Fang, Luyuan, ALABS; Ash, Gerald R (Jerry), ALABS; Yakov Rekhter;
[email-masked]