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

From: Srikanth Chavali <[email-masked]>
Date: Thu, 06 May 2004 20:23:16 -0400

I am forwarding my response to Pekka's email to clarify things..

srikanth chavali

-------- Original Message --------
Subject: 	Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG 
document
Date: 	Wed, 05 May 2004 10:37:02 -0400
From: 	Srikanth Chavali <[email-masked]>
To: 	Pekka Savola <[email-masked]>, [email-masked]
References: 	<[email-masked]>

Hi Pekka,
              Thanks for your comments. I have replied to your model 
related comments:

Pekka Savola wrote:

>A high-level comment:
>---------------------
>
>The model seems to be so that when the receiving BGP speaker receives the
>number of routes which exceed a warning, stop or reset limit, it sends a
>message to inform the other router about exceeding this limit, raising a
>warning, askit it to stop, or reset the session.
>
The draft does'nt say/mean/intend this.

>
>There is another way to specify this as well.  Each router sends the other,
>_in advance_, when opening the BGP session, their prefix limits; these
>values are stored per peer.  The sending router checks the length of its
>adj-ribs-out for the peer whether it exceeds any of these limits, and raises
>warnings, stops advertising, etc. as appropriate.  (In that model, no 
>compliant router ever exceeds these limits, even temporarily.)
>
The above is what the draft specifies. Please note that the exchange of 
the prefix limit capability in the OPEN
message (Not the Dynamic capability) achieves what you're saying above. 
This is already specified in the draft.

So here's the mechanism in short:

1. Exchange the capability in OPEN message. The BGP speakers note them 
and are expected to honor them.
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).
3. If stop limit hit stop route advertisements. Again send Dynamic 
capability whose purpose is as mentioned in 2.

We're working on revising the text for clarity, but if there's anything 
specific in the text which caused mis-interpretation please
let us know and we will address it.

Thanks

srikanth chavali

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 6 May 2004 20:56:12 -0400

Srikanth,

>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

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 6 May 2004 20:56:12 -0400

Srikanth,

Thanks,

--John

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Thu, 6 May 2004 18:35:34 -0700

Dynamic capability is not intended as a signalling mechanism of
  state - that is how I see it. It is mainly to exchange high level
  session capabilities.  I would rather use a different mechanism that 
  is for the purpose of such exchanging dynamic state changes.

  To quote from the DYN-CAP draft :

   -------------
   Currently BGP capabilities [BGP-CAP] are only advertised in the OPEN
   message during the session initialization. In order to enable a new
   capability or remove an existing capability (such as an Address
   Family support [BGP-MP]), an established session may need to be
   reset, which would disrupt other services running over the session.
   -------------

  I would like to understand why the authors think that dynamic
  capabilites is an appropriate medium for this purpose.

  thanks,
  Chandra Appanna.

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Thu, 6 May 2004 18:35:34 -0700

-------------

  thanks,
  Chandra Appanna.

---

From: Keyur Patel <[email-masked]>
Date: Thu, 06 May 2004 18:52:56 -0700

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

---

From: Keyur Patel <[email-masked]>
Date: Thu, 06 May 2004 18:52:56 -0700

-Keyur

---

From: Srikanth Chavali <[email-masked]>
Date: Thu, 06 May 2004 21:59:38 -0400

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

---

From: Srikanth Chavali <[email-masked]>
Date: Thu, 06 May 2004 21:59:38 -0400

Keyur/John,

srikanth chavali

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 6 May 2004 22:55:25 -0400

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

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 6 May 2004 22:55:25 -0400

Srikanth,

Regards,

--John

---

From: Pekka Savola <[email-masked]>
Date: Fri, 7 May 2004 08:12:29 +0300 (EEST)

> Can you comment as to why warning as a local policy is not sufficient 

I'm not sure if I understand the point 2, above.  (I'm not sure which 
router's "local policy" are you talking about.)

Yes, prefix-limits should not be re-negotiated when a limit has been 
hit.  That's part of the administrative procedures.

Yes, it would also seem ill-advised to send the "you have exceeded 
your prefix limits" -message after the exceeding, as the damage has 
already been done.

Let's assume BGP speaker A advertises prefixes to speaker B, and B has 
set up prefix limits and wishes to inform A about them.

The BGP speaker A must support at least a warning level, and may
support also "code red" level.  That is, when Adj-Ribs-out (for B) on
speaker A reaches the warning level, log a warning message to the
administration of speaker A.  When the advertised prefix count on A
reaches the "code red" level, it needs to log a "code red" message,
and may stop advertising new prefixes.  The stopping part is IMHO not
that important.

On the other hand, Speaker B has set prefix limits to the direction of 
A.  If the advertised prefix count exceed the warning level, a warning 
is logged to the local administration.  If the prefix count exceeds 
the "code red" level, stop accepting new prefixes or reset the 
session and log a "code red" alert.  Note that these have to be done 
always and in any way, because speaker B cannot be sure that speaker A 
is honoring the limits it has sent.  If A honors them, most of these 
errors never get activated.

And just to clarify -- the part about speaker B is already out there 
and requires no notifications at all.  The part people are interested 
of is notifying another BGP speakers of the configured and enforced 
limits, so that the other speakers can log local warning messages or 
prevent the bgp sessions from being reset.

(I don't have have strong opinions on whether it's needed to be able 
to send other limits rather than just the warning.  The warning is 
most important, but the stop might be useful as well.  Reset doesn't 
appear to be necessary at all.)

Hope this clarifies the "scenarios" or "operator requirements" I had 
in mind.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Fri, 7 May 2004 08:12:29 +0300 (EEST)

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 7 May 2004 09:42:54 -0400

At 8:12 AM +0300 5/7/04, Pekka Savola wrote:
>I'm not sure if I understand the point 2, above.

Just to be sure we all understand each other, point 2 above is 
Srikanth, the question below it which refers to local policy it is 
me.  Multiple quote levels can get confusing.

>(I'm not sure which router's "local policy" are you talking about.)

I was referring to the (warning generation) policy on Speaker A in 
your example quoted below.  The text that you omitted from your quote 
elaborates on the question, but my point is that A can and should 
generate the warning on its own, B doesn't need to signal A telling 
it when to generate a warning.  It's sufficient for B to tell A ahead 
of time what the maximum limit is, and rely on A to notice when it's 
approaching it.

In other words, I think we're agreeing on this point -- at any rate I 
agree with the way you've written out the scenario in your example. 
What I do NOT think is needed is if the example were instead to say:

"When the Adj-RIB-In on B (from A) reaches the warning level, B sends 
A a message requesting that A log a warning message to its 
administration."

which is what I understand draft-chavali to propose.  I don't think B 
needs to nag A -- A already knows how many routes it has sent as 
you've shown in your example.

>and may stop advertising new prefixes.  The stopping part is IMHO not
[snip]

Regards,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 7 May 2004 09:42:54 -0400

[snip]

Regards,

--John

---

From: Srikanth Chavali <[email-masked]>
Date: Fri, 07 May 2004 17:53:32 -0400

Chandra ,
              At the point this was written there was no other way of 
information messaging. We did have
Notification in mind per AFI/SAFI with non-fatal codes/subcodes i.e non 
peer session tearing in nature and
which would not impact the FSM. However since Dynamic capability was 
readily available we chose that.
If you see any specific issues with this we can discuss on ways to 
achieve the Notification way i described above.
We're open for discussions on that.

Thanks

srikanth chavali

---

From: Srikanth Chavali <[email-masked]>
Date: Fri, 07 May 2004 17:53:32 -0400

Chandra ,

Thanks

srikanth chavali