Subject: [Idr] signalled prefix limits -- contrasting approaches

From: "John G. Scudder" <[email-masked]>
Date: Thu, 6 May 2004 13:03:27 -0400

Folks,

Regarding prefix limits, it seems to me that there are at least two 
questions for the WG to answer:

First, do we want to take signalled prefix limits as a work item?

Assuming that the answer is "yes", then:

Second, what is the preferred approach?  One of the two that have 
been presented (draft-chavali-bgp-prefixlimit-02.txt, 
draft-keyur-prefixlimit-orf-00.txt)? Something else?

For the interest of forwarding that discussion, I guess I should 
suggest that draft-keyur-prefixlimit-orf-00.txt be a WG document.  I 
hereby do so.

Having done so, below I'll contrast the draft-chavali and draft-keyur 
approaches.  Also, I should point out that draft-keyur can be seen as 
a fully-elaborated statement of what I said at the mic back in 
Minneapolis, so this is not the first time I've suggested this 
approach in an IDR WG forum.

Summarizing the principal differences:

draft-chavali proposes to use dynamic capabilities.  draft-keyur 
proposes to use ORFs.

draft-chavali proposes multiple thresholds, albeit only one mandatory 
one.  draft-keyur proposes one.  The use of multiple, optional 
thresholds drives draft-chavali to have a more elaborate encoding 
than draft-keyur uses.

draft-chavali appears to propose dynamic signalling triggered by 
limits being exceeded.  It's hard to evaluate this properly since I 
can't come up with an unambiguous interpretation of section 4.  In 
any event, draft-keyur does not propose any such dynamic signalling.

That's it in a nutshell.  Now I will discuss the reasons for our choices.

As regards ORFs vs. dynamic capabilities, one may observe that ORFs 
have exactly the desired semantics: supported ORF types are exchanged 
at connection startup, they are typed according to AFI/SAFI, they are 
a way for a router to export its policy to its peer and they can be 
dynamically revised.  All this semantic goodness is part of the basic 
ORF spec, which is already widely implemented and deployed.  Dynamic 
capabilities certainly could be used to exchange such limits, but 
then again any other arbitrary message type could too.  The appeal of 
ORFs is that again, they are already widely implemented and are a 
good semantic fit.  Our experience is that it's not very hard to add 
prefix limit exchange to an implementation that already has ORFs and 
a locally-configured max-prefix feature.

As regards multiple thresholds, Enke Chen already covered this in an 
earlier message to the list, and I agree with what he wrote, but I'll 
say it again in my own words.  The warning limit is not needed since 
warnings can and should be generated as a matter of local policy.  As 
for the reset limit, draft-chavali implicitly acknowledges that it's 
not really needed when it says "It MUST be noted here that this 
situation will never be encountered if adhered to the draft."  Since 
neither limit is required to deliver a useful feature, the KISS 
principle suggests leaving them out.  The obvious riposte to this 
point is that since the features are optional, they need not be 
implemented, to which I would respond, if you don't expect them to be 
implemented, why clutter the spec and risk confusing implementors? 
Other BGP related specs are largely free of optional features 
(internally to themselves anyway), and I think this is a good 
thing... we have enough trouble implementing, deploying, 
interoperating and debugging the mandatory ones!

(As a bit of a tangent, the WG has previously considered at least one 
mechanism to allow arbitrary conditions to be non-destructively 
signalled, and decided at that time not to pursue it.  If we _do_ now 
think that we need such signalling, as the warning limit appears to 
do, perhaps it would be best to re-open the general topic instead of 
building a feature-specific version.  Note that draft-keyur does not 
in any way preclude supporting such a feature in the future if we 
define one.)

As regards dynamic signalling, I found it challenging even to 
understand exactly what draft-chavali is proposing.  To take one 
example, in 4.2.1, it says that when the warning limit is 
encountered, "B generates a dynamic capability" and furthermore 
"either A or B or both of them could generate this message".  Without 
getting into any further details of how the dynamic signalling of 
limits being crossed would be done, I'll discuss the reason why I'm 
generally not attracted to in-band dynamic warnings in any form. 
First, it's unnecessary.  In the example of 4.2.1, A knows how many 
routes it's gotten from B -- it doesn't need B to tell it.  B knows 
how many routes it's sent to A -- it doesn't need A to tell it.  Once 
again, the KISS principle suggests that this feature is therefore not 
required.  Second, it's dangerous.  Consider the case where B's 
advertised route count is hovering near the warning limit, and in 
fact frequently crosses back and forth over the warning limit.  This 
could easily result in excessive warning signalling over the BGP 
session, with resultant bad effects.  Of course, a thoughtful 
implementation would take steps to avoid this, but at the cost of 
additional complexity... and anyway, why leave the door open to 
possible bugs in whatever throttling scheme would be employed (or not 
employed, by a naive implementation)?

To sum up the reasons for the three differences I've identified, they 
are in the case of ORF, a pragmatic engineering choice where we 
selected what appears to us to be the best tool for the job, and in 
the cases of multiple thresholds and dynamic signalling, KISS.

Regards,

--John

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

---

From: Enke Chen <[email-masked]>
Date: Thu, 06 May 2004 16:24:07 -0700

Hi, Folks:

I am in favor of the ORF based solution proposed in <draft-keyur-...>
as it seems to be simpler and clearer than <draft-chavali-...>. The
prefix limit seems to fit the ORF mechanism perfectly.

Regards,

-- Enke

> Message-Id: <p060204bcbcc015693aed@[192.168.42.3]>
> To: [email-masked]
> From: "John G. Scudder" <[email-masked]>
> Subject: [Idr] signalled prefix limits -- contrasting approaches
> Date: Thu, 6 May 2004 13:03:27 -0400
> 
> Folks,
>

---

From: Enke Chen <[email-masked]>
Date: Thu, 06 May 2004 16:24:07 -0700

Hi, Folks:

Regards,

-- Enke

---

From: Srikanth Chavali <[email-masked]>
Date: Thu, 06 May 2004 20:42:11 -0400

John ,
        If you read the draft carefully you should notice there that the 
warning mechanisms can be turned off during
the capability exchange in OPEN and/or DYNAMIC CAPABILITY messages. 
There are 2 values that apply to the
warning indicator. One to turn it on and the other to turn it off 
according to the need.
These have been added after discussions with the service providers. It 
had been found that these are useful for debugging purposes.

While i concede the scope for improving the text the mechanism is fairly 
simple :

1. Exchange capabilities in OPEN which peering BGP speakers honor.
2. If  messaging indicators are turned on send the dynamic capability 
messages when the
respective limits are reached.
3. Changes to the limit get exchanged (Dynamic Capability message) and 
honored.

srikanth chavali

John G. Scudder wrote:

> Second, what is the preferred approach?  One of the two that have been 
> presented (draft-chavali-bgp-prefixlimit-02.txt, 
> thresholds drives draft-chavali to have a more elaborate encoding than 
> draft-keyur uses.
>
> can't come up with an unambiguous interpretation of section 4.  In any 
> event, draft-keyur does not propose any such dynamic signalling.
>
> capabilities certainly could be used to exchange such limits, but then 
> again any other arbitrary message type could too.  The appeal of ORFs 
> is that again, they are already widely implemented and are a good 
> semantic fit.  Our experience is that it's not very hard to add prefix 
> limit exchange to an implementation that already has ORFs and a 
> locally-configured max-prefix feature.
>
> (internally to themselves anyway), and I think this is a good thing... 
> we have enough trouble implementing, deploying, interoperating and 
> debugging the mandatory ones!
>
> example, in 4.2.1, it says that when the warning limit is encountered, 
> "B generates a dynamic capability" and furthermore "either A or B or 
> both of them could generate this message".  Without getting into any 
> further details of how the dynamic signalling of limits being crossed 
> would be done, I'll discuss the reason why I'm generally not attracted 
> to in-band dynamic warnings in any form. First, it's unnecessary.  In 
> the example of 4.2.1, A knows how many routes it's gotten from B -- it 
> doesn't need B to tell it.  B knows how many routes it's sent to A -- 
> it doesn't need A to tell it.  Once again, the KISS principle suggests 
> that this feature is therefore not required.  Second, it's dangerous.  
> Consider the case where B's advertised route count is hovering near 
> the warning limit, and in fact frequently crosses back and forth over 
> the warning limit.  This could easily result in excessive warning 
> signalling over the BGP session, with resultant bad effects.  Of 
> course, a thoughtful implementation would take steps to avoid this, 
> but at the cost of additional complexity... and anyway, why leave the 
> door open to possible bugs in whatever throttling scheme would be 
> employed (or not employed, by a naive implementation)?
>

---

From: Srikanth Chavali <[email-masked]>
Date: Thu, 06 May 2004 20:42:11 -0400

John ,

srikanth chavali