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

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

On Thu, 15 Apr 2004, Susan Hares wrote:
> 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.

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.

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

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.

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

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

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.

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

---

From: Enke Chen <[email-masked]>
Date: Mon, 26 Apr 2004 12:10:51 -0700

Hi, Sue:

At the last IDR meeting, there were several suggestions about simplifying
the spec..  One particular one (by jgs?) is to just advertise the prefix
limit, something like <afi, safi, max-limit>.  As a BGP speaker knows how
many prefixes it has advertised to a particular peer, the <afi, safi, max>
received from a peer should be sufficient for a local BGP to take action
(such as generate warning, stop advertisement, ...)

*If* the prefix-limit advertisement is needed, I suggest that we take the
approach of just advertising <afi, safi, max-limit>. The current draft
is just too complicated for the feature.

-- Enke

> From: "Susan Hares" <[email-masked]>
> To: "Pekka Savola" <[email-masked]>
> Cc: "Yakov Rekhter" <[email-masked]>, <[email-masked]>
> 
> 
> Pekka:
> 
> Thanks for the input.  Your vote is for=20
> the simple version.=20
> 
> Sue
> 
> 
> >=20
> Remember, if a peer advertises 100 prefixes, you don't set the prefix=20
> limits to 101 prefixes or even 110 prefixes, but probably something=20
> > =09
> >=20
> No, I think I disagree with this.  Why would they have to be treated=20
> differently?  It's the number of prefixes per peer that counts, not=20
> >=20
> >=20
> Currently, adding prefix-limits does not drop a session, so it's=20
> required that sessions aren't dropped if the prefix-limits are changed=20
> either.  That means that if prefix-limit negotiation is specified, it=20
> =20
> > History:=20
> > 	mechanism (ORF, Soft Notify) to support the dynamic features -=20
> > 	we added the rest.
> >=20
> > 	do it by prefix lengths. =20
> >=20
> > 	we made these other features optional. =20
> >=20
> > is the basic part of the initial draft?  Did you dis-like the =
> additions
> > (ORF, Soft Notify) and or the optional sub-codes?=20
> >
> admittedly, I haven't looked at it much) or using prefix lengths. =20
> So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and=20
> compact to me.
> 
> --=20

---

From: Enke Chen <[email-masked]>
Date: Mon, 26 Apr 2004 12:10:51 -0700

Hi, Sue:

-- Enke

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Apr 2004 06:17:41 -0700

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: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Apr 2004 06:17:41 -0700

Sue,

Yakov.