Subject: Checking support for draft-white-bounded-longest-match-01.txt

From: Alex Zinin <[email-masked]>
Date: Tue, 19 Jul 2005 15:03:10 -0700

Folks-

 We had some discussion on this draft about a year ago, and while a few
 people provided technical comments, it wasn't very clear if there's
 community support behind publishing this through the IETF process.

 I would like to solicit community feedback on this document. Please send
 your message to the list and indicate:

   a) if you belive this document should be progressed to an Informational
      RFC as an IETF document (vs an individual request to the RFC Editor)
      or not.

   b) if you still have any technical comments or concerns on the document.

 Please note that silence is interpreted as lack of interest in this case,
 so if you believe this document is useful--please speak up.

 Thank you.
 
-- 
Alex
http://www.psg.com/~zinin

-------- Original Message --------
Subject: I-D ACTION:draft-white-bounded-longest-match-01.txt
Date: Fri, 15 Jul 2005 15:50:03 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Bounding Longest Match Considered
	Author(s)	: R. White, T. Hardie
	Filename	: draft-white-bounded-longest-match-01.txt
	Pages		: 8
	Date		: 2005-7-15
	
Some ASes currently use length-based filters to manage the size of
    the routing table they use and propagate.  This draft explores an
    alternative to length-based filters which allows for more automatic
    configuration and which provides for better redundancy.

    Rather than use a filter, this draft proposes a method of modifying
    the BGP [RFC1771] longest match algorithm by setting a bound on the
    prefix lengths eligible for preference.  A bound would operate on
    long prefixes when covering route announcements are available; in
    certain circumstances it would cause a router to prefer an aggregate
    over a more specific route announcement.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-white-bounded-longest-match-01.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-white-bounded-longest-match-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-white-bounded-longest-match-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

---

From: John Leslie <[email-masked]>
Date: Tue, 19 Jul 2005 20:27:32 -0400

>     RFC as an IETF document (vs an individual request to the RFC Editor)

   I see little point in it: the mechanism seems harder to tune to a
particular number of routes to advertise than most manual methods.
Neither does it seem to offer any better route-flapping defense than
current methods.

>  b) if you still have any technical comments or concerns on the document.

   My concerns are operational; and I don't have any suggestions for
small changes. I have some very fundamental worries about any automatic
marking of routes which happen to overlap; but I can't see how to remove
that feature while leaving the fundamental idea intact.

--
John Leslie <[email-masked]>