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

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

> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

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

---

From: Tony Li <[email-masked]>
Date: Fri, 14 May 2004 14:08:32 -0700

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: Tony Li <[email-masked]>
Date: Fri, 14 May 2004 14:08:32 -0700

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 May 2004 15:08:07 -0700

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 May 2004 15:08:07 -0700

Tony,

R.

---

From: Tony Li <[email-masked]>
Date: Fri, 14 May 2004 15:15:37 -0700

Write a cron job that sends them email.  Sheesh.

Tony

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

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

---

From: Tony Li <[email-masked]>
Date: Fri, 14 May 2004 15:15:37 -0700

Tony

---

From: Eric Rosen <[email-masked]>
Date: Mon, 17 May 2004 13:00:48 -0400

> 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: Eric Rosen <[email-masked]>
Date: Mon, 17 May 2004 13:00:48 -0400

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 17 May 2004 11:22:40 -0700

Tony,

Could you please clarify whether (a) you are in favor or against
accepting signalled prefix limit as an IDR WG item, and if yes,
then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
or draft-keyur-prefixlimit-orf-00.txt) would you favor.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 17 May 2004 11:22:40 -0700

Tony,

Yakov.

---

From: Tony Li <[email-masked]>
Date: Mon, 17 May 2004 12:05:18 -0700

Yakov,

I am against accepting signalled prefix limits as an IDR WG item.

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 17 May 2004 12:05:18 -0700

Yakov,

Tony

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 18 May 2004 06:51:11 -0700

Eric,

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 18 May 2004 06:51:11 -0700

Eric,

Yakov.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 18 May 2004 11:35:00 -0400

> accepting signalled prefix limit as an IDR WG item,

In favor.  

> if yes,

draft-keyur.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 18 May 2004 11:35:00 -0400

In favor.  

draft-keyur.

---

From: Vivek Menezes <[email-masked]>
Date: Fri, 21 May 2004 18:24:05 -0700

> accepting signalled prefix limit as an IDR WG item, and if yes,

It appears that we are unnecessarily making the protocol more complex with
no added advantage. The right thing for a peer to do when it reaches it maximum
configured number of prefixes is to shutdown the session. I like the
idea (not necessarily
the proposal ) of supporting multiple BGP sessions, with each session
for a different protocol, so that different protocols do not disrupt
each others.

passing around a signal between peers that adds no value in their
decision process
is unnecessary.

The answer is "NO"

Vivek.

---

From: Vivek Menezes <[email-masked]>
Date: Fri, 21 May 2004 18:24:05 -0700

The answer is "NO"

Vivek.