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

From: Yakov Rekhter <[email-masked]>
Date: Thu, 15 Apr 2004 06:59:54 -0700

Folks,

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. 

Yakov.

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

---

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

Jeff:

	As an editor of the draft,
I'd like a little bit more detail on what
you think exceeds the level of effort or
complexity.

	The three parameters (warning, stop receive,
drop) [sub-codes 1-3] or the additional parameters
(sub-codes 4,5,6,etc). 

Sue

PS - the additional pieces were put in response to
	a discussion at the IETF.

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

   Not to limit cool/smart thinking, but I believe that
   the level of effort and/or complexity here exceeds
   the return.

   This has never been an issue in any of the major SP
   networks that I've played with.

   While protecting at the edges is of interest, sharing or
   communicating policy [such as thresholds] has been more
   of an area of concern (risk-wise) than a priority.

   An e-mail, phone call, or contractual arrangement should
   suffice in other cases.

  - jsb

> Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST)
> From: Pekka Savola <[email-masked]>
> To: Yakov Rekhter <[email-masked]>
> 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:
> 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
>
>

---

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

Jeff:

Sue

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

  - jsb

---

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

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 20 Apr 2004 07:52:08 -0500

> for comments is April 29, 2004.

This draft addresses an important issue, and proposes a reasonable approach to address the issue.  I support this becoming a WG document.

Jerry

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 26 Apr 2004 13:53:43 -0400

Pekka:

Thanks for the input.  Your vote is for 
the simple version. 

Sue

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]]
Sent: Friday, April 23, 2004 1:17 AM
To: Susan Hares
Cc: Yakov Rekhter; [email-masked]
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
document

> 		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: "Susan Hares" <[email-masked]>
Date: Tue, 27 Apr 2004 10:17:15 -0400

Narrowing down to one would be fine.

Sue

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Tuesday, April 27, 2004 9:18 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
document 

Sue,

<with the WG co-chair hat off>

If one uses ORF to pass prefix limit, then I think there is no need
to also exchange this limit in the BGP Open message - all you
need to carry in the Open message is the Capability that indicates support
for the prefix limit ORF type (and the appropriate AFI/SAFI). This
is because of the way how ORF operates (quoting from the ORF spec):

   Consider a BGP speaker that advertises the Cooperative Route Filtering
   Capability indicating its willingness to receive a particular set of
   <AFI, SAFI, ORF-Type> from its peer, and that receives the Cooperative
   Route Filtering Capability indicating the desire of the peer to send a
   particular set <AFI, SAFI, ORF-Type> to the speaker. If for a given
   <AFI, SAFI> the intersection between these two sets are not-empty, the
   speaker SHOULD NOT advertise to the peer any routes with that <AFI,
   SAFI> prior to receiving from the peer any ROUTE-REFRESH message
   carrying that <AFI, SAFI>, where the message could be either without
   any ORF entries, or with one or more ORF entry and When-to-refresh
   field set to IMMEDIATE. If, on the other hand, for a given <AFI, SAFI>
   the intersection between these two sets is empty, the speaker SHOULD
   follow normal BGP procedures.

In the above pay especial attention to the "speaker SHOULD NOT advertise" 
part.

I am also a bit concerned with support for two ways of advertising
the prefix limit: one via OFR and another via Dynamic Capabilities.
Why narrowing this down to one is not enough ?

Yakov.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 27 Apr 2004 10:17:15 -0400

Sue

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Tuesday, April 27, 2004 9:18 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
document 

Sue,

Yakov.