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

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. 

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

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 11 May 2004 19:26:39 -0700 (PDT)

Susan Hares writes:

> 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

I don't think that it makes sense at this point to advance any
of the 2 documents to WG status. The problem is not well enought
understood, imho.

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

Signalled prefix limits are not an application. There maybe
applications that require it. The working group should consider taking
those as WG items rather than the particular details of the
solution. 

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

Nay. warning should be a local decision. ignore prefix is not well
defined enought... how do you recover from that and who is responsible
for doing so ? disconnect is the only one i understand at the moment
what it means.

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

We would need to know what problem is being solved. The answer may be
different depending on it.

I sugest also that we do not take unqualified input. i.e. i would like
to see people describe the goal and then what items they believe best
work as a solution to the problem rather than just throwing a number.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 11 May 2004 19:26:39 -0700 (PDT)

Pedro.