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

From: "Susan Hares" <[email-masked]>
Date: Thu, 15 Apr 2004 16:26:00 -0400

Pekka:

<hat-notification-on>
	This is in my hat as an editor of the draft.
	Not in my co-chair hat. 
<hat-notification-off> 

Can you clarify something here:
	1) Your need - informing the remote peer of
		warning limits, stop receive limits, and drop limits
		and SNMP traps, logs etcs

		is the basis for the draft.

	2)  Providers we talk to had 2 cases:
	
		1) creeping VPN prefix limits
		2) dump of whole routing table

		The need to treat the two differently.

	3)  Set until changed - that's the rub

	The providers wanted to negotiate the capabilties and
	upgrade the capabilities without dropping the connect.

	Is that what you mean as well? If so, could you comment
	on what is complex.

History: 
	We started this out with capabilities on open, and dynamic
	capabilities.  Due to some vendor's request to include other
	mechanism (ORF, Soft Notify) to support the dynamic features - 
	we added the rest.

	Other service providers said, Love the function but could you
	do it by prefix lengths.  

	In an effort to get something working for all these folks,
	we made these other features optional.  

What part don't you like?  Cause everything you stated you wanted --
is the basic part of the initial draft?  Did you dis-like the additions
(ORF, Soft Notify) and or the optional sub-codes? 

Do you think we should go back to the initial draft simplistic model?

Sue

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]]
Sent: Thursday, April 15, 2004 11:29 AM
To: Yakov Rekhter
Cc: [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
document

On Thu, 15 Apr 2004, Yakov Rekhter wrote:
> We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt
> as an IDR WG document. Please send comments to the list. The deadline
> for comments is April 29, 2004. 

The applicability does not seem to be sufficiently clear.

That is, people use prefix limits for a *reason*.  Once set, they're 
set until they are changed.  There's no urgent need to specify 
anything here.

However, I agree that it might not hurt to have some option that could 
be used to inform the peer on your limits, so that:
 - the operator of the peer could notice this when examining the 
neighbor's info (i.e., when contemplating about advertising new 
prefixes), or
 - if the peer exceeded the prefix limits, the peer's operator would 
notice that a warning/stop threshold has been reached (this could 
result in an SNMP trap, flashing led, or whatever.)

I fail to see a need for anything more than that, and the current 
document *seems* to be more complex than that.

Unless I'm mistaken, I'm not sure if going forward with this draft is 
a good idea.

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

_______________________________________________
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: Pekka Savola <[email-masked]>
Date: Fri, 23 Apr 2004 08:16:48 +0300 (EEST)

> 		is the basis for the draft.

We don't really *need* this, because we're monitoring the number of
prefixes advertised by peers.  If they go over the top, an alarm
sounds in the NOC.  There is no need to inform the peer of the prefix
limits we use, as no prefixes should be dropped based on that, and if
they are, the peer has been badly misbehaving and deserves what it
got.

Remember, if a peer advertises 100 prefixes, you don't set the prefix 
limits to 101 prefixes or even 110 prefixes, but probably something 
like 200 or 500 prefixes.

Our threat model here is, "we want to stop peers from accidentally
advertising the whole Internet or a lot more routes than is normal to
us."

I.e., a properly administered systems do not need this option.

But I would not object to having a simple option if that's what others
see useful.  I would object to creating a complex option, because that
seems to go too much beyond the cost/benefit curve for an option which
is not needed at all in the first place.

> 		The need to treat the two differently.

No, I think I disagree with this.  Why would they have to be treated 
differently?  It's the number of prefixes per peer that counts, not 
per AFI/SAFI etc. used, or the manner by which they're transmitted.

You protect your gear at the edge of the network, from either your
peers or your customers (if you import their routes into VPN), so
distinguishing per VPN doesn't seem to be all that useful.

> 	Is that what you mean as well? If so, could you comment

Currently, adding prefix-limits does not drop a session, so it's 
required that sessions aren't dropped if the prefix-limits are changed 
either.  That means that if prefix-limit negotiation is specified, it 
must not require a session reset, yes.
 
> Do you think we should go back to the initial draft simplistic model?

It seems to me that if dynamic capabilities is a required-to-implement
mechanism, soft-notify is useless or even problematic (what if you are
doing both?).  Similarly, I fail to see any need for ORF (but
admittedly, I haven't looked at it much) or using prefix lengths.  
Those who would like to distinguish prefix length in the
prefix-limiter are probably confusing inbound policy with appropriate
prefix-limits.

So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and 
compact to me.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Apr 2004 08:16:48 +0300 (EEST)