Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt

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

John:

Just to make sure I understand you:

Can you have 3 limits per AFI/SAFI?

 a) Warn limit (warn me if we hit this limit)
 b) Ignore further prefixes (ignore further prefixes)
 c) Disconnect upon getting to these numbers
	of prefixes received. 

I think Mo wants to have 3 limits. Let's use
an example of 3 limits for an AFI/SAFI in
a VPN:
	a) Warn - 2000
	b) Ignore - 3000
	c) Disconnect - 20,000

Now, you send ORF with AFI/SAFI-1,..
Can you fill in the rest of the details
to determine if you can provide these
three limits.  Can you negotiate a
value for these three limits? 

Can you re-negotiate the limits? 

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Monday, May 10, 2004 6:28 PM
To: Mo Miri
Cc: [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt

At 1:46 PM -0400 5/10/04, Mo Miri wrote:
>One major difference in this document versus the 
>others recently submitted on the same topic, is 
>the fact that BGP remains to be established and 
>only the prefixes outside the limit are dropped. 
> Therefore, the service remains to be reliable 
>for the existing prefixes, which are within the 
>acceptable range.

I assume that by "others recently submitted" you 
are referring to draft-keyur-prefixlimit-orf-00.txt.  Assuming 
that to be the case, I would like to point out 
that draft-keyur allows for either method of 
enforcement -- the session may be dropped, or 
prefixes dropped.  Here is a relevant excerpt 
from section 4.1.1 of the draft.  As you can see, 
the latter option is exactly the option you 
describe:

    Corrective actions MAY include dropping the BGP session or refusing
    to accept new prefixes in excess of the PrefixLimit.

    If the former option -- dropping the BGP session -- is chosen, the
    router MUST indicate this in advance by advertising its PrefixLimit
    ORF with the Match flag set to DENY.  Also, by default it SHOULD NOT
    automatically reestablish the session.

    If the latter option -- refusing to accept new prefixes -- is chosen,
    the router MUST accept modifications to already-accepted prefixes,
    and it MUST accept withdrawals of already-accepted prefixes.  If
    prefixes are withdrawn, the received prefix count will drop below the
    announced PrefixLimit and new prefixes SHOULD be accepted, again up
    to but not exceeding the limit.  Prefixes which are refused SHOULD
    NOT contribute to the received prefix count.

    We note that the option of refusing to accept new prefixes will
    likely lead to desynchronization of the BGP session and is a flawed
    solution at best; operator intervention will be required in order to
    restore synchronization (for example, through correction of routing
    policies and a subsequent route-refresh).

So I have to disagree that this is a "major 
difference".  In fact, both drafts permit the 
option of dropping prefixes.

Since you've brought up this topic I'd also like 
to draw your attention to today's exchange 
between Jeff Haas and myself regarding the perils 
of dropping prefixes.  (Subject: "Re: [Idr] 
signalled prefix limit as an IDR WG work item".)

Regards,

--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: "John G. Scudder" <[email-masked]>
Date: Tue, 11 May 2004 19:45:16 -0400

>  c) Disconnect upon getting to these numbers

This is actually two questions:  Are the limits per AFI/SAFI?  And, 
how many limits are there?

ORFs are intrinsically per AFI/SAFI, so whatever limits are supported 
would be per AFI/SAFI.  The answer to the first sub-question is "yes".

As for three limits, it would be possible in principle to modify our 
draft to support three limits in the signalling part -- it's just 
another 64 bits, piece of cake.  I just haven't been told any reason 
yet why that's needed.

Note that an implementation would typically have all three of these 
limits -- it's just that the warn and disconnect limits would be 
computed locally as a function of what you've called the "ignore 
further prefixes" limit above and we just call the prefix-limit. 
This is elaborated further below.

So the answer to the second question is a qualified "yes" with room 
for further discussion.

>value for these three limits?

Limit b:  In our model, we'd send an ORF with the prefix-limit 3000.

Limit a:  The receiver of the ORF would determine locally when it 
wanted to issue a warning, computed as a function of the 
prefix-limit.  If the administrator of that router had configured 
something to the effect of "warn-percent 66" then the warn-limit 
would be 66% of 3000, or (about) 2000.

Limit c:  The originator of the ORF would locally configure a 
disconnect-limit of 20000.  This would not be signalled to the peer, 
but then again a compliant peer would not exceed 3000 anyway so a 
compliant peer wouldn't need to know the disconnect-limit.  A 
noncompliant peer is... well, noncompliant.

>Can you re-negotiate the limits?

Yes.  Re-advertise actually -- as someone, maybe Pekka, pointed out 
there's no actual negotiation that takes place.  This follows from 
the base ORF spec.

Regards,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 11 May 2004 19:45:16 -0400

Regards,

--John