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

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

---

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

I agree.  We should make boxes better.  And when we realize that we've 
made a mistake, then
we should turn around and fix it.  Not patch up the hole in the side of 
the ship and keep
on sailing as if we didn't just hit a reef.

Tony

On May 14, 2004, at 3:25 PM, Fang, Luyuan, ALABS wrote:

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

---

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

Tony