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: "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:
>>>
>>>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: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 14:55:37 -0400

Chandra: 

The next paragraph in dynamic capabilities (after
the one you quoted says: 

   "This document defines a new BGP capability termed "Dynamic
   Capability", which would allow the dynamic update of capabilities
   over an established BGP session. This capability would facilitate
   non-disruptive capability changes by BGP speakers."

The maximum prefix negotiation is to allow
changing of these limits in a non-disruptive fashion.

The providers set a warning, a ignore limit (stop taking
more prefixes), and a disconnect.

As an example, it can help the providers
solve these problems 

Problem 1: Want to limit a AFI/SAFI to a certain 
		maximum limit of prefixes

Problem 2: Want to allow a "warning" threshold before
		the limit so I can re-negotiate with the
		providers.  The providers want this large
		enough so they can spend 1 week or 2 weeks
		tracking down the problem.  That way it's not
		an emergency.

Problem 3: Providers want to immediately disconnect those
		people who erroneously send a full routing table
		dump via such a BGP client.

(By the way, apparently misconfiguration causes problem
 number 3 alot. Ringing a large bell for problem 3 helps
 remove other problems.)

So, the dynamic capabilities - Like the ability to handle
AFI/SAFI pairs allows re-negotiation of these limits
without dropping the configuration.

John Scudder/Enke Chen have sent two types of comments:

  1) Not all 3 limits are needed (warning, ignore, disconnect)
  2) ORF are simplier than Dynamic capabilities to 
	implement these features 

For comment 1: 3 limits, I think the co-authors on our
draft (Luyuan Faung (AT&T) and Mo Miri) started us down
this path to be able to get the limits.  They want to
get this in a non-disruptive manner. 

So, that's why I think the Dynamic capabilities fit
just right to fix this problem.  

Sue

PS - I know I've not responded to comment 2. 

     That's an interesting technical discussion,
     that we'll take up in a different email messages.
	
	Both have pro's and con's.  As we indicated in 
	draft-chavali-bgp-prefixlimit-01, we think both
	ORFs and Dynamic capabilities can work together
	or separately.  I promise more on that in a momemnt.

-----Original Message-----
From: Chandrashekhar Appanna [mailto:[email-masked]]
Sent: Thursday, May 06, 2004 9:36 PM
To: Srikanth Chavali
Cc: [email-masked]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]

  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: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 14:55:37 -0400

Chandra: 

Sue

	

-----Original Message-----
From: Chandrashekhar Appanna [mailto:[email-masked]]
Sent: Thursday, May 06, 2004 9:36 PM
To: Srikanth Chavali
Cc: [email-masked]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]

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

  thanks,
  Chandra Appanna.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:23:55 -0400

John:

The warning is there in your draft as well
on both sides.  So, I'm a bit confused.
You indicate you should give information to
local SNMP information.  The negotiation
comes between the customer and the provider. 
Both should get warnings. 

Perhaps we need to go back to the 3 scenarios.

1) Warn me at a limit X (to local input)
2) Ignore prefixes at limit Y
3) Disconnect the boxes at limit Z 

I think they want 3 limits for these
three things.  Can you tell me how your
specification would do this? 

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Friday, May 07, 2004 7:06 PM
To: Fang, Luyuan, ALABS
Cc: Srikanth Chavali; Keyur Patel; idr
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]

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: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:28:01 -0400

John:

The purpose is not to "nag" A, but
to negotiate limits after a warning
has be hit.  Supposedly:

	Warn - We get 1 week to talk
		 to customer and reset the limit

		The ISP resolves this limit with
		the customer and resets the warning
		limit, the stop limit to something higher.
		
		Disconnect limit may/may not hit this.
	(Dynamic capabilities/ ORF can reset
	  while the BGP connection is running)

So, in your description below.. I don't see
how 1 limit and a lot of assumptions gives
the same clear negotiation and tracking of ORF
information.

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Friday, May 07, 2004 9:43 AM
To: Pekka Savola
Cc: Srikanth Chavali; [email-masked]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]

At 8:12 AM +0300 5/7/04, Pekka Savola wrote:
>On Thu, 6 May 2004, John G. Scudder wrote:
>>  Can you comment as to why warning as a local policy is not sufficient
>>  to achieve this end?
>
>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.

>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.
[snip]

Regards,

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:32:33 -0400

John:

The warnings are remotely signaled
so that both sides of BGP connection know the limits.

The warnings are sent to a local SNMP or
your friendly Cisco CLI stations. At that point,
our friends at the super-noc would contact
customer, determine fix, sit down change
configs to have BGP re-negotiate (ORF/Dyn-Cap)
mechanisms on the fly.

Both BGP get to agree on the new amount
and go on.  

I think you understood this.. but I wanted
to make sure we are in alignment on the problem.

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
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,

Regards,

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:34:10 -0400

Local warning is meant aid engendering of
some NOC action.  If the NOC action
is to up the limit, "re-negotiation"
will make sure both sides keep the current
limits.

Yes -- it's about making sure both sides
have this answer.  I doubt they will 
share configuration file information. 

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Thursday, May 06, 2004 8:56 PM
To: Srikanth Chavali
Cc: [email-masked]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]

Srikanth,

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: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:23:55 -0400

John:

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Friday, May 07, 2004 7:06 PM
To: Fang, Luyuan, ALABS
Cc: Srikanth Chavali; Keyur Patel; idr
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]

Luyuan,

Thanks,

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:28:01 -0400

John:

		

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Friday, May 07, 2004 9:43 AM
To: Pekka Savola
Cc: Srikanth Chavali; [email-masked]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]

[snip]

Regards,

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:50:20 -0400

Keyur:

I think I've sent this a few times:

 My understanding from Mo and Luyuan,
 and other service providers are:

	a)Warning levels - let them get time
				 to fix the problems,

	b) Ignore prefix levels - limits memory
	c) Disconnect - prevents full routing
			    table sending.

Just how does the reset prefix limit provide this?

The purpose of negotiated policy instead of "local
policy (Aka configuiration)" is that it is exchanged
in BGP, saved in the MIB, and re-negotiated upon the
fly.

So, mechanisms aside.  I really think that the reset
limit is not sufficient for this purposes.

If you can accomplish this action with one, please
let me know.  All I see that you are falling back
to non-negotiation on the part of these limits.
Saying "check the config".  

Well statistics from research institutions
(yankee group, etc) give 30% to 50% of network 
outages are based on configuration
errors.  I guess it made sense if the service providers
want to include a few more things in negotiated,
tracked parameters.

Sue 

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

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: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:32:33 -0400

John:

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
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,

Regards,

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:34:10 -0400

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Thursday, May 06, 2004 8:56 PM
To: Srikanth Chavali
Cc: [email-masked]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]

Srikanth,

Thanks,

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 20:06:13 -0400

Pekka:

The prefix-limits are not re-negotiated without
having an administrative input in either draft.

keyur-prefix draft has only 1 limit per ORF. Hit it
and either ignore, stop receiving or disconnect.
Or try to re-negotiate that one limit. 

If you want to preset multiple limits, choose
that option.  My understanding is that
you choose warn and ignore prefix/stop receiving.

Sue

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]]
Sent: Friday, May 07, 2004 1:12 AM
To: John G. Scudder
Cc: Srikanth Chavali; [email-masked]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]

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

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: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:50:20 -0400

Keyur:

Sue 

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

-Keyur

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 20:06:13 -0400

Pekka:

Sue

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]]
Sent: Friday, May 07, 2004 1:12 AM
To: John G. Scudder
Cc: Srikanth Chavali; [email-masked]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]