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: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 20:19:02 -0400

Enke:

Do you favor 3 prefix limits or
1?  John says you favor 1 limit.

Please confirm.

Sue

-----Original Message-----
From: Enke Chen [mailto:[email-masked]]
Sent: Thursday, May 06, 2004 7:24 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] signalled prefix limits -- contrasting approaches 

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: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 20:19:02 -0400

Enke:

Please confirm.

Sue

-----Original Message-----
From: Enke Chen [mailto:[email-masked]]
Sent: Thursday, May 06, 2004 7:24 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] signalled prefix limits -- contrasting approaches 

Hi, Folks:

Regards,

-- Enke

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 20:55:53 -0400

Folks:

To be formal as well, as a co-author (not as a WG chair)
I would like to suggest that the draft-chavali-bgp-prefixlimit-02.txt
be adopted as a working group draft.  

I would also like to disagree with John on his characterization of
the two drafts.  I am purposely ignoring anything but requirements
and technical issues.  Comparisons of KISS or editorial moments 
on John's or the co-author will not be considered.  

Sue
=============================
Comments based on Draft

=============================

I think there are 3 questions:

1) Do you want signalled prefix limits as a work item?

2) What signalled prefix limits do you want?

	Do you want 3 levels: warning, ignore prefix (stop), and
			      disconnect.

	on what level: All prefixes, some prefixes, one prefix.

  After that point, we can decide upon the mechanisms that
  best fit that point.  When we got into this, we promised our
  co-authors that were service providers that this was the
  most important point.  2 service providers have chimed up
  and said all three.   Other service providers have said 2.
  I see implementers disagreeing, but not service providers.

3) What mechanisms?

	OPEN + Dyn-Caps + ORF or some combinatinon. 
	
	Our earlier drafts had combinations of all of these mechanisms.
	If you use more than one, you need to set precedence.

Let's decide based on the provider input.  We've gotten
lots of implementers; not very many providers.  The providers
tend to ask for more.  Hmm.

==================
4) As to comparison of Drafts:

3 summary points:

1) Multiple thresholds - yes, because we believe the
		service providers are asking for them.

2) Dynamic negotiation - 

      I think you have this confused.
	The dynamic negotiation is not "automatic".
	Never!  It just doesn't drop the session.  

	We did the same thing with ORFs in draft-01.
	You do the same thing in your draft.

	We provide "optional" mechanisms to tell each
	side the state of the world (I sent X, I have received Y).
	For some providers that provides a check on buggy software for
	a new feature.  (Hmm. self debugging).

3) ORFs and Dynamic Capabilities are both dynamic.
	
	You can set the Route Refresh a-going without
	dropping the connection.  At least with ORFs you
	should be able to.  I've sent you questions about
	your "DENY" flag that disconnects. I can't get
	a common sense out of that text so I sent questions. 

So.. Differences on mechanism (not the multiple thresholds)
are:

1) ORF only (keyur draft) or OPEN + DYN-CAP (draft-chavali-bgp-prefixlimit-02/00)
				  or OPEN + ORF (Draft-chavali-bgp-prefixlimit-01)
				  or OPEN + ORF + Dyn-Cap (draft-chavali-bgp-prefixlimit-01.txt)
	
======================
Non differences:

1) State of Code - ORF and Dynamic Capabilities are both deployed
2) State of Specification
	- Dynamic Capabilities and Route Refresh lack detailed
		error conditions that will handle this.
3) State of Maximum Prefix Specification
4) KISS approach -

=======
Error conditions on Dynamic capabilities/Route Refresh 

  a) Route Refresh is vague in many portions of the specification.
	 Error processing is not really complete.  With these added changes,
	 we may need to add the suggested error comments into that specification.
	 Especially if we add any prefix limits and re-negotiation capabilities.

   b) Dynamic Capabilities is vague too!

		Not that Dynamic Capabilities are clean either.  As we both know,
		dyn-cap--> (stop afi/safi X)
							<--- afi/safi X data
							<--- dyn-cap (xxx)

			gives you a problem with handling of this data.  Our implementations
			cope, but I agree with you this can be fixed.

	2) The rest of John's comments on "optional", etc.