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

From: "Fang, Luyuan, ALABS" <[email-masked]>
Date: Fri, 7 May 2004 17:44:18 -0500

This warning mechanism is useful from the perspective of operations. With the external messages it ensures that the customers receive the warning on the limit reached condition and take immediate actions, rather than for the service providers  manually calling up the customers.

This might not be applied to all the BGP peers but to some of the peers that we deem fit for it. 

Since it can be turned off, it should limit the impact from the processing standpoint. Of course, if this consumes fair amount of resources of the boxes, we need to take that into consideration.

Luyuan Fang
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of John G.
Scudder
Sent: Thursday, May 06, 2004 10:55 PM
To: Srikanth Chavali
Cc: Keyur Patel; idr
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]

Srikanth,

Yes, I read -00 back around the Minneapolis meeting.  Is there a 
specific section of the document you believe addresses the questions? 
Since you refer to "service providers perspective" I went and reread 
section 2.2 of -00 ("Current Service Provider Perspective") and it 
doesn't appear to answer either question.

Note that I don't need to be convinced of the value of issuing 
warnings.  Rather, I'm questioning if they need to be remotely 
signalled.

Regards,

--John

At 9:59 PM -0400 5/6/04, Srikanth Chavali wrote:
>Keyur/John,
>                  Did you guys had a chance to read 00.txt vesion of 
>this draft? We had incorporated the views of the Service Providers 
>and the discussions we had with them there. If you did'nt let me 
>know i will either point you to that or send you a copy of it.  That 
>should answer your questions as well as the service providers 
>perspective on that.  In the latest versions we had trimmed that 
>text for simplicity sake.
>
>srikanth chavali
>
>Keyur Patel wrote:
>
>>Also, can you comment on as to why the "reset prefix limit" as a 
>>part of local policy is not sufficient (considering this *may* be 
>>taken into consideration when prefix limits have already been 
>>reached)? Resetting the session is just one of the possible local 
>>actions that can be taken (when the prefix limit is reached). Why 
>>just enumerate one of them in the draft?
>>
>>-Keyur
>>
>>John G. Scudder wrote:
>>
>>>Srikanth,
>>>
>>>At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>>>
>>>>2. If warning limit hit send the Dynamic capability (if indicator set).
>>>>It serves dual purpose as warning and/or renegotiate the capabilites.
>>>>It gives operators enough time to (debug errors)/(change limits).
>>>
>>>
>>>
>>>Can you comment as to why warning as a local policy is not 
>>>sufficient to achieve this end?
>>>
>>>In particular it would be great if you could address the 
>>>observation that whether generated locally or remotely, the 
>>>warning is liable to be a function of the Adj-RIB size (which is 
>>>known by both peers) and the prefix-limit value (which is likewise 
>>>known to both peers). Furthermore the action of the router to 
>>>bring the warning to the attention of the operator is inherently 
>>>going to be a local matter.
>>>
>>>Thanks,
>>>
>>>--John

_______________________________________________
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: "John G. Scudder" <[email-masked]>
Date: Fri, 7 May 2004 19:05:44 -0400

Luyuan,

I certainly don't mean to question that there is operational goodness 
from having warnings emitted by customer boxes.  In fact, I agree.

Rather, my point is that the warning doesn't need to be sent by the 
provider side box to the customer side box.  Since the provider box 
would tell the customer box the prefix limit ahead of time, and since 
the customer box knows the size of its own Adj-RIB-Out towards the 
provider box, the customer box can and should generate the warning 
locally.

The effect would be the same, the difference being that one approach 
requires extra messaging and one doesn't.  In either case, the 
customer receives a warning when the limit is reached.

Note that no matter what, some aspect of the warning is beyond the 
provider box's control -- even if we went with a solution where the 
provider box transmits a warning to the customer box, the customer 
box still has to properly present that warning to the customer as a 
log message, SNMP trap, or whatnot.  So, regardless of whether 
warnings are generated locally or remotely, it's inescapable that the 
customer box controls whether and how the warning is delivered. 
Given that, why would we want to go to the effort of generating them 
remotely instead of getting the same benefit for lower cost by doing 
it locally?

Thanks,

--John

At 5:44 PM -0500 5/7/04, Fang, Luyuan, ALABS wrote:
>This warning mechanism is useful from the perspective of operations. 
>With the external messages it ensures that the customers receive the 
>warning on the limit reached condition and take immediate actions, 
>rather than for the service providers  manually calling up the 
>customers.
>
>Since it can be turned off, it should limit the impact from the 
>processing standpoint. Of course, if this consumes fair amount of 
>resources of the boxes, we need to take that into consideration.
>
>Luyuan Fang
>[email-masked]
>
>

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 7 May 2004 19:05:44 -0400

Luyuan,

Thanks,

--John