Re: [Idr] draft-ietf-idr-rfc3065bis-02.txt to Draft Standard

["John G. Scudder" <[e-mail]>]

A few responses in line below.

At 2:49 PM +0300 5/28/04, Pekka Savola wrote:
...
>substantial
>-----------
>
>  - section 9 describes how MEDs cause issues.  This is apparently
>caused by the (originally) too lax specification on MED/local-pref
>treatment inside the conferedaration: a mere MAY.

That's not the basic issue.  The basic issue is what's described in 
RFC 3345 (which is referenced in the text you're referring to).  In 
short, the MED issue is a day-one bug, but it's in the base BGP spec, 
not confederations or route reflectors.

>Now the question is: would it make sense to take a stance on this to improve
>the situation for the future, e.g., as a SHOULD ?

I don't think that would fix it.

>- section 9, 2nd para, describes improper configuration of confederations
>causing a lot of problems, but does not go at more length to actually
>describe what that improper configuration would be.  Such a warning appears
>to be useless due to it's lack of sufficient detail.  Maybe add a bit more?

Rather than trying to make the section comprehensive, I'd prefer to 
direct the reader to RFC 3345 which does have a much more detailed 
discussion of the topic.  We could add the sentence

    For a more thorough discussion of these issues, see [9].

to that paragraph.

>The same applies to the 3rd paragraph: what is the scenario, and how to do
>(or not do) it?
>
>semi-editorial
>--------------
>
>  - uses the old RFC2026 boilerplate, should be updated to RFC3668 at least
>by the new policy.
>
>  - the same applies to the IPR statements/boilerplates.  Further, the
>best place for these would be around the copyright statement, not before the
>acknowledgements.
>
>  - add a note in the Introduction/Abstract that this doc Obsoletes RFC
>3065.
>
>  - section 5.1 has been updated in the new BGP spec a lot.  Should we have
>an updated version here, just do nothing, or specify the rules so that they
>do not depend on the language of the BGP spec?

For neatness we should probably bring it more or less [*] up to date 
with the draft -23 language.  Unfortunately I don't see a clean way 
to specify the rules independent of the base spec, since they in fact 
_aren't_ independent -- they modify the base spec's rule set.  If you 
have an idea for how to do this cleanly, please share.

[*] While looking at the draft -23 language I noticed a bug, which I 
don't think we'll want to propagate into 3065bis.  That is, draft -23 
in the "advertises a route to an external peer" section doesn't 
consider the possibility that the AS_PATH might be empty.  This bug 
doesn't exist in 3065bis; I'm not sure if it exists in older base 
spec drafts or 1771.

>- the references must be split to informative and normative.  Note that you
>must not place any other documents than BCPs, Full Standards and Draft
>Standards in the normative references section.
>
>editorial
>---------
>
>  - the status of this document -boilerplate includes the keywords; these
>should be moved to e.g. the Introduction, as the boilerplate ends up being
>removed in the RFC publication, and the keywords would go missing.
>
>  - the same section also has a dummy "product of (null) WG, "send comments
>to (null)" paragraph.  Remove?
>
>  - abstract and introduction talk about 'proposals'.  Replace with
>'documents' or 'specifications'?
>
>  - section 4 title: s/Segement/Segment/
>
>  - the document uses a lot of "SHALL".  When specifying what must be
>implemented, a "MUST" is should be equivalent, except it sounds much better
>at least to me :)
>
>  - in section 7.2, item 2), s/AS_CONFED_SET/AS_CONFED_SET but/ ?

No, that would change the meaning of the sentence (to be incorrect). 
If it would be less confusing, we could try something like

    2) Otherwise, examine the first non-AS_CONFED_* segment in the
       path.  If it is an AS_SEQUENCE, consider the neighbor AS to
       be the leftmost AS_SEQUENCE AS.

The point is that in certain rare cases, it could be an AS_SET in 
which case the neighbor AS is unknown.

Thanks for the review,

--John

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



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA16687 for <[e-mail]>; Fri, 28 May 2004 14:40:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTm5B-0007BJ-6x; Fri, 28 May 2004 14:27:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTlyf-0005ST-D6 for [e-mail]; Fri, 28 May 2004 14:21:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21026 for <[e-mail]>; Fri, 28 May 2004 14:21:07 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTlye-0005Be-D6 for [e-mail]; Fri, 28 May 2004 14:21:08 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTlxd-0004j1-00 for [e-mail]; Fri, 28 May 2004 14:20:06 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BTlwY-0003sW-00 for [e-mail]; Fri, 28 May 2004 14:18:58 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 28 May 2004 11:17:25 -0700
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4SIIPXl010600; Fri, 28 May 2004 11:18:26 -0700 (PDT)
Received: from [10.32.14.235] (dhcp-64-101-214-222.cisco.com [64.101.214.222]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA20254; Fri, 28 May 2004 14:18:24 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p06020406bcdd2c51fa56@[10.32.14.235]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 28 May 2004 14:17:53 -0400
To: Pekka Savola <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Idr] draft-ietf-idr-rfc3065bis-02.txt to Draft Standard
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

A few responses in line below.

At 2:49 PM +0300 5/28/04, Pekka Savola wrote:
...
>substantial
>-----------
>
>  - section 9 describes how MEDs cause issues.  This is apparently
>caused by the (originally) too lax specification on MED/local-pref
>treatment inside the conferedaration: a mere MAY.

That's not the basic issue.  The basic issue is what's described in 
RFC 3345 (which is referenced in the text you're referring to).  In 
short, the MED issue is a day-one bug, but it's in the base BGP spec, 
not confederations or route reflectors.

>Now the question is: would it make sense to take a stance on this to improve
>the situation for the future, e.g., as a SHOULD ?

I don't think that would fix it.

>- section 9, 2nd para, describes improper configuration of confederations
>causing a lot of problems, but does not go at more length to actually
>describe what that improper configuration would be.  Such a warning appears
>to be useless due to it's lack of sufficient detail.  Maybe add a bit more?

Rather than trying to make the section comprehensive, I'd prefer to 
direct the reader to RFC 3345 which does have a much more detailed 
discussion of the topic.  We could add the sentence

    For a more thorough discussion of these issues, see [9].

to that paragraph.

>The same applies to the 3rd paragraph: what is the scenario, and how to do
>(or not do) it?
>
>semi-editorial
>--------------
>
>  - uses the old RFC2026 boilerplate, should be updated to RFC3668 at least
>by the new policy.
>
>  - the same applies to the IPR statements/boilerplates.  Further, the
>best place for these would be around the copyright statement, not before the
>acknowledgements.
>
>  - add a note in the Introduction/Abstract that this doc Obsoletes RFC
>3065.
>
>  - section 5.1 has been updated in the new BGP spec a lot.  Should we have
>an updated version here, just do nothing, or specify the rules so that they
>do not depend on the language of the BGP spec?

For neatness we should probably bring it more or less [*] up to date 
with the draft -23 language.  Unfortunately I don't see a clean way 
to specify the rules independent of the base spec, since they in fact 
_aren't_ independent -- they modify the base spec's rule set.  If you 
have an idea for how to do this cleanly, please share.

[*] While looking at the draft -23 language I noticed a bug, which I 
don't think we'll want to propagate into 3065bis.  That is, draft -23 
in the "advertises a route to an external peer" section doesn't 
consider the possibility that the AS_PATH might be empty.  This bug 
doesn't exist in 3065bis; I'm not sure if it exists in older base 
spec drafts or 1771.

>- the references must be split to informative and normative.  Note that you
>must not place any other documents than BCPs, Full Standards and Draft
>Standards in the normative references section.
>
>editorial
>---------
>
>  - the status of this document -boilerplate includes the keywords; these
>should be moved to e.g. the Introduction, as the boilerplate ends up being
>removed in the RFC publication, and the keywords would go missing.
>
>  - the same section also has a dummy "product of (null) WG, "send comments
>to (null)" paragraph.  Remove?
>
>  - abstract and introduction talk about 'proposals'.  Replace with
>'documents' or 'specifications'?
>
>  - section 4 title: s/Segement/Segment/
>
>  - the document uses a lot of "SHALL".  When specifying what must be
>implemented, a "MUST" is should be equivalent, except it sounds much better
>at least to me :)
>
>  - in section 7.2, item 2), s/AS_CONFED_SET/AS_CONFED_SET but/ ?

No, that would change the meaning of the sentence (to be incorrect). 
If it would be less confusing, we could try something like

    2) Otherwise, examine the first non-AS_CONFED_* segment in the
       path.  If it is an AS_SEQUENCE, consider the neighbor AS to
       be the leftmost AS_SEQUENCE AS.

The point is that in certain rare cases, it could be an AS_SET in 
which case the neighbor AS is unknown.

Thanks for the review,

--John

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA08910 for <[e-mail]>; Fri, 28 May 2004 08:06:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTg0D-0000U7-LG; Fri, 28 May 2004 07:58:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTftu-00087O-E3 for [e-mail]; Fri, 28 May 2004 07:51:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22557 for <[e-mail]>; Fri, 28 May 2004 07:51:48 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTftt-0000CM-NI for [e-mail]; Fri, 28 May 2004 07:51:49 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTfsw-0007cl-00 for [e-mail]; Fri, 28 May 2004 07:50:51 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BTfsI-0007Dm-00 for [e-mail]; Fri, 28 May 2004 07:50:11 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4SBnc527443 for <[e-mail]>; Fri, 28 May 2004 14:49:38 +0300
Date: Fri, 28 May 2004 14:49:38 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] draft-ietf-idr-rfc3065bis-02.txt to Draft Standard
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Mon, 24 May 2004, Yakov Rekhter wrote:
> This is to start the IDR WG Last Call on advancing
> draft-ietf-idr-rfc3065bis-02.txt to Draft Standard.

And the implementaion & interop report is at..?
 
> During the Last Call it would be greatly appreciated if folks would
> read the document and comment on it to the IDR mailing list. In
> other words, we need "yes, looks good" or "should fix this and
> that", not just silence.

Yes, this is good.  There may be some issues worth ironing out now 
though.

substantial
-----------

 - section 9 describes how MEDs cause issues.  This is apparently
caused by the (originally) too lax specification on MED/local-pref
treatment inside the conferedaration: a mere MAY.

Now the question is: would it make sense to take a stance on this to improve
the situation for the future, e.g., as a SHOULD ?

- section 9, 2nd para, describes improper configuration of confederations
causing a lot of problems, but does not go at more length to actually
describe what that improper configuration would be.  Such a warning appears
to be useless due to it's lack of sufficient detail.  Maybe add a bit more?

The same applies to the 3rd paragraph: what is the scenario, and how to do
(or not do) it?

semi-editorial
--------------

 - uses the old RFC2026 boilerplate, should be updated to RFC3668 at least
by the new policy.

 - the same applies to the IPR statements/boilerplates.  Further, the
best place for these would be around the copyright statement, not before the
acknowledgements.

 - add a note in the Introduction/Abstract that this doc Obsoletes RFC 
3065.

 - section 5.1 has been updated in the new BGP spec a lot.  Should we have
an updated version here, just do nothing, or specify the rules so that they
do not depend on the language of the BGP spec?

- the references must be split to informative and normative.  Note that you
must not place any other documents than BCPs, Full Standards and Draft
Standards in the normative references section.

editorial
---------

 - the status of this document -boilerplate includes the keywords; these
should be moved to e.g. the Introduction, as the boilerplate ends up being
removed in the RFC publication, and the keywords would go missing.

 - the same section also has a dummy "product of (null) WG, "send comments
to (null)" paragraph.  Remove?

 - abstract and introduction talk about 'proposals'.  Replace with
'documents' or 'specifications'?

 - section 4 title: s/Segement/Segment/

 - the document uses a lot of "SHALL".  When specifying what must be
implemented, a "MUST" is should be equivalent, except it sounds much better
at least to me :)

 - in section 7.2, item 2), s/AS_CONFED_SET/AS_CONFED_SET but/ ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA15092 for <[e-mail]>; Tue, 25 May 2004 18:22:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSjrt-0003My-N1; Tue, 25 May 2004 17:53:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSjWD-0001iT-Fw for [e-mail]; Tue, 25 May 2004 17:31:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23036 for <[e-mail]>; Tue, 25 May 2004 17:31:27 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSjWC-0002iq-4Z for [e-mail]; Tue, 25 May 2004 17:31:28 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSjV8-0002Ym-00 for [e-mail]; Tue, 25 May 2004 17:30:23 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BSjU9-0002In-00 for [e-mail]; Tue, 25 May 2004 17:29:21 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4PLSpBm057305 for <[e-mail]>; Tue, 25 May 2004 14:28:51 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4PLSpJ93853 for <[e-mail]>; Tue, 25 May 2004 14:28:51 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 25 May 2004 14:28:51 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] draft-ietf-idr-rfc2858bis-06.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

The revised text has just a couple of editorial changes
(replacing "should" with "SHOULD" in two places and replacing
"will" with "MUST" in one place).

Yakov. 
------- Forwarded Message

Date:    Tue, 25 May 2004 15:51:08 -0400
From:    [e-mail]
To:      [e-mail]
cc:      [e-mail]
Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-06.txt

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF
.

	Title		: Multiprotocol Extensions for BGP-4
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2858bis-06.txt
	Pages		: 11
	Date		: 2004-5-25
	
Currently BGP-4 is capable of carrying routing information only for
IPv4. This document defines extensions to BGP-4 to enable it to carry
routing information for multiple Network Layer protocols (e.g., IPv6,
IPX, etc...). The extensions are backward compatible - a router that
supports the extensions can interoperate with a router that doesn't
support the extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the mess
age.  
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-ietf-idr-rfc2858bis-06.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-rfc2858bis-06.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.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-rfc2858bis-06.txt

- --OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


- --OtherAccess--

- --NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce

- --NextPart--




------- End of Forwarded Message


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA14840 for <[e-mail]>; Tue, 25 May 2004 18:19:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSjmD-0007EM-SH; Tue, 25 May 2004 17:48:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSifV-0008D7-VG for [e-mail]; Tue, 25 May 2004 16:37:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17219 for <[e-mail]>; Tue, 25 May 2004 16:36:59 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSifU-0004Av-J8 for [e-mail]; Tue, 25 May 2004 16:37:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSieV-00042x-00 for [e-mail]; Tue, 25 May 2004 16:36:00 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BSidX-0003q0-00 for [e-mail]; Tue, 25 May 2004 16:34:59 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4PKYK127247; Tue, 25 May 2004 23:34:20 +0300
Date: Tue, 25 May 2004 23:34:20 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Subject: private ASN usage [Re: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd) 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Cc: Andrew Lee <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Mon, 24 May 2004, Curtis Villamizar wrote:
> In message <[e-mail]>, Andrew Lee writes:
> > 
> > > :   The most common technique as an alternative to full mesh routing is
> > > :   to use BGP route reflectors [2].  Conferedations [3] and/or dividing
> > > :   the autonomous system to multiple private AS numbers have also been
> > > :   used.  IDRP itself has never been standardized by the IETF and can be
> > > :   considered obsolete.
> > > 
> > > Two comments here aside from some punctuation suggestions:
> > > 1. Do people typically deploy private AS's outside of a confederation
> > >    context?
> 
> 
> The NSFNET had about 20 public AS numbers just in the NSFNET T3
> backbone alone.
> 
> Confederations and private AS removed the need to do that sort of
> thing.
> 
> For a long time UUNET had 701 and 702 (Europe) and other providers had
> multiple AS.
> 
> I'm not sure if any have multiple AS other than those that use
> confederations these days.

This was already out of scope here, but yes, I think private ASNs are 
being used without conferederations.  In our network, we definitely 
use them.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings




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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA06550 for <[e-mail]>; Tue, 25 May 2004 16:58:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSi9t-0006M8-5v; Tue, 25 May 2004 16:04:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BShx8-0003xL-Sl; Tue, 25 May 2004 15:51:10 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12982; Tue, 25 May 2004 15:51:09 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Tue, 25 May 2004 15:51:08 -0400
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-06.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Multiprotocol Extensions for BGP-4
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2858bis-06.txt
	Pages		: 11
	Date		: 2004-5-25
	
Currently BGP-4 is capable of carrying routing information only for
IPv4. This document defines extensions to BGP-4 to enable it to carry
routing information for multiple Network Layer protocols (e.g., IPv6,
IPX, etc...). The extensions are backward compatible - a router that
supports the extensions can interoperate with a router that doesn't
support the extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ietf-idr-rfc2858bis-06.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-rfc2858bis-06.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.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-rfc2858bis-06.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA20925 for <[e-mail]>; Tue, 25 May 2004 14:20:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSgHd-0004TT-8D; Tue, 25 May 2004 14:04:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSg61-0000MY-3H for [e-mail]; Tue, 25 May 2004 13:52:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03394 for <[e-mail]>; Tue, 25 May 2004 13:52:11 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSg5z-0004Ee-VY for [e-mail]; Tue, 25 May 2004 13:52:12 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSg51-00049O-00 for [e-mail]; Tue, 25 May 2004 13:51:12 -0400
Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx with esmtp (Exim 4.12) id 1BSg4H-00044J-00 for [e-mail]; Tue, 25 May 2004 13:50:25 -0400
Received: from [192.35.165.177] (bedford.lex.arbor.net [204.118.128.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id CA90294664 for <[e-mail]>; Tue, 25 May 2004 11:50:17 -0600 (MDT)
Mime-Version: 1.0 (Apple Message framework v613)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Danny McPherson <[e-mail]>
Subject: Re: [Idr] draft-ietf-idr-rfc3065bis-02.txt to Draft Standard
Date: Tue, 25 May 2004 11:50:06 -0600
To: idr <[e-mail]>
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On May 25, 2004, at 9:53 AM, Jeffrey Haas wrote:
>
> This must be SHALL NOT

Yep, will fix..

> The above text could be modified to something like the following
>
> It is a error for a BGP speaker to receive an update message from an
> external confederation peer which does not have AS_CONFED_SEQUENCE as 
> the
> first segment. [...]

I'll fix this and the other issues you brought up.

Thanks for the useful detailed review!

-danny


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA14292 for <[e-mail]>; Tue, 25 May 2004 13:12:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSf7Y-0005uC-9w; Tue, 25 May 2004 12:49:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSeJ7-0005B4-24 for [e-mail]; Tue, 25 May 2004 11:57:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21887 for <[e-mail]>; Tue, 25 May 2004 11:57:34 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSeJ6-0005Qz-5L for [e-mail]; Tue, 25 May 2004 11:57:36 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSeHi-0005Cg-00 for [e-mail]; Tue, 25 May 2004 11:56:11 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BSeFX-0004nf-00 for [e-mail]; Tue, 25 May 2004 11:53:55 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id ADBA02D48E9 for <[e-mail]>; Tue, 25 May 2004 11:53:25 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 49575-01-9 for <[e-mail]>; Tue, 25 May 2004 11:53:14 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 004E82D4872 for <[e-mail]>; Tue, 25 May 2004 11:53:14 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i4PFrDK25126 for [e-mail]; Tue, 25 May 2004 11:53:13 -0400 (EDT)
Date: Tue, 25 May 2004 11:53:13 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] draft-ietf-idr-rfc3065bis-02.txt to Draft Standard
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Comments:

MS-style line feeds have crept into the document.

In the table of contents, could we keep the columns justified to the same
level?

On page 4, could we keep the header "Member-AS Number" with the following
text?

   When implementing BGP Confederations Section 5.1.2 of [1] is replaced

Add in a comma:

   When implementing BGP Confederations, Section 5.1.2 of [1] is replaced

A critical error seems to have slipped in:

:    When implementing BGP Confederations Section 5.1.2 of [1] is replaced
:    with the following text:
: [...]
: 
:    a) When a given BGP speaker advertises the route to another BGP
:       speaker located in its own autonomous system, the advertising
:       speaker SHALL modify the AS_PATH attribute associated with the
:       route.

This must be SHALL NOT

This seems to have remained unnoticed as well:

:    It is a error for a BGP speaker to receive an update message from a
:    confederation peer which does not have AS_CONFED_SEQUENCE as the
:    first segment.  If a BGP speaker receives such an update message, it
:    SHALL treat the message as having a malformed AS_PATH according to
:    the procedures of [1] Section 6.3 ("Update message error handling").

Consider the case where a confederation router peering with a 
non-confederation router receives a route.  This route, when being
propagated via iBGP to a confederation peer WILL NOT have its AS_PATH
modified.

The above text could be modified to something like the following

It is a error for a BGP speaker to receive an update message from an
external confederation peer which does not have AS_CONFED_SEQUENCE as the
first segment. [...]


Don't references need to be split between normative and informative?

Remove last empty page.

On Mon, May 24, 2004 at 08:49:14AM -0700, Yakov Rekhter wrote:
> Folks,
> 
> This is to start the IDR WG Last Call on advancing
> draft-ietf-idr-rfc3065bis-02.txt to Draft Standard.
> 
> During the Last Call it would be greatly appreciated if folks would
> read the document and comment on it to the IDR mailing list. In
> other words, we need "yes, looks good" or "should fix this and
> that", not just silence.
> 
> The deadline for comments is June 7, 2004.
> 
> Yakov.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA00481 for <[e-mail]>; Tue, 25 May 2004 10:56:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSd7x-00049e-Fc; Tue, 25 May 2004 10:42:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BScqM-0000ru-DC for [e-mail]; Tue, 25 May 2004 10:23:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15160 for <[e-mail]>; Tue, 25 May 2004 10:23:48 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BScqL-0006FI-G1 for [e-mail]; Tue, 25 May 2004 10:23:49 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BScpQ-0006BU-00 for [e-mail]; Tue, 25 May 2004 10:22:52 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BScoV-00065y-00 for [e-mail]; Tue, 25 May 2004 10:21:55 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6CE892D48E9; Tue, 25 May 2004 10:21:24 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 46195-02-12; Tue, 25 May 2004 10:21:12 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 35E652D48BC; Tue, 25 May 2004 10:21:12 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i4PELCM22572; Tue, 25 May 2004 10:21:12 -0400 (EDT)
Date: Tue, 25 May 2004 10:21:12 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Cc: [e-mail], Pekka Savola <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Yakov,

On Mon, May 24, 2004 at 04:22:20PM -0700, Yakov Rekhter wrote:
> Let's keep in mind that the purpose of this document is to
> move rfc1863 to historic, and *not* to describe the various uses
> of the term "route server" (this is not to say that describing
> various uses of the term "route server" is useless, it is just
> that it is outside the scope of *this* document).

My original issue with the text was that it was limiting the definition
of route server.  That said:

> with the following:
> 
>    In the context of this document the term "RFC 1863 route server"
>    is used to refer to a route server as specified in RFC1863.
>    Other uses of the term "route server" are outside the scope
>    of this document.

I'm cool with this.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA25715 for <[e-mail]>; Mon, 24 May 2004 22:31:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSRcj-0002vG-H1; Mon, 24 May 2004 22:25:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSRUP-0002WM-AX for [e-mail]; Mon, 24 May 2004 22:16:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22894 for <[e-mail]>; Mon, 24 May 2004 22:16:22 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSRUN-00018s-JT for [e-mail]; Mon, 24 May 2004 22:16:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSRTQ-00011g-00 for [e-mail]; Mon, 24 May 2004 22:15:24 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BSRSU-0000t9-00 for [e-mail]; Mon, 24 May 2004 22:14:26 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4P2CI0N044658; Mon, 24 May 2004 22:12:18 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd) 
In-reply-to: Your message of "Mon, 24 May 2004 16:22:20 PDT." <[e-mail]> 
Date: Mon, 24 May 2004 22:12:18 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Cc: [e-mail], Jeffrey Haas <[e-mail]>, Pekka Savola <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>, Yakov Rekhter writes
:
> 
> With this in mind how about replacing:
> 
>    In the modern terminology, the term "route server" refers to a
>    designated, normal BGP speaker set up for specific purposes such as
>    data collection or retrieval; such route servers do not implement RFC
>    1863.  For clarity, in the context of this document the term "RFC
>    1863 route server" is used to refer to a route server as specified in
>    RFC 1863.
> 
> with the following:
> 
>    In the context of this document the term "RFC 1863 route server"
>    is used to refer to a route server as specified in RFC1863.
>    Other uses of the term "route server" are outside the scope
>    of this document.


Good suggestion on the wording.

A little history on this.

Bay Networks was still Wellfleet and Wellfleet had no BGP
implementation at all until about June 1994 when they finished a BGP-3
implementation shortly after BGP-3 became obsoleted by the CIDR
deployment in April 1994.  Welfleet was having a lot of trouble with
the BGP policy code and Cisco's policy code just plain didn't work
unless you had a very small number of policy statements.  There was
also a problem shared by most commercial routers at the time in that
they didn't have enough RAM to properly support BGP.  At the time
gated was by far the best BGP-4 code available; the policy code worked
and scaled well, the bugs later studied by Craig Labovitz were not
present in gated, and you could get pizza box computers that were fast
and had plenty of RAM.  Deploying a router with one peering and no
routing policy seemed like an attractive idea to some people (at least
people at Wellfleet if no where else).  Dimitri was hoping to find an
acceptable solution that didn't involve a full BGP implementation on
the router.  The idea didn't fly but the RFC lives on, so far.

Curtis

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA12235 for <[e-mail]>; Mon, 24 May 2004 19:38:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSOwK-0000bN-QG; Mon, 24 May 2004 19:33:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSOqk-0000HL-PE for [e-mail]; Mon, 24 May 2004 19:27:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16268 for <[e-mail]>; Mon, 24 May 2004 19:27:17 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSOqj-0000Vo-Av for [e-mail]; Mon, 24 May 2004 19:27:17 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSOpl-0000QR-00 for [e-mail]; Mon, 24 May 2004 19:26:17 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BSOon-0000Gj-00 for [e-mail]; Mon, 24 May 2004 19:25:17 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4ONOlBm046262; Mon, 24 May 2004 16:24:47 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4ONOlJ20487; Mon, 24 May 2004 16:24:47 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Andrew Lee <[e-mail]>
Subject: Re: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd) 
In-Reply-To: Your message of "Mon, 24 May 2004 10:41:38 CDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 24 May 2004 16:24:47 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Andrew,

> > :   The most common technique as an alternative to full mesh routing is
> > :   to use BGP route reflectors [2].  Conferedations [3] and/or dividing
> > :   the autonomous system to multiple private AS numbers have also been
> > :   used.  IDRP itself has never been standardized by the IETF and can be
> > :   considered obsolete.
> > 
> > Two comments here aside from some punctuation suggestions:
> > 1. Do people typically deploy private AS's outside of a confederation
> >    context?
> > 2. While IDRP never made it as an IETF specification, I believe it is
> >    still a valid ISO specification and thus our opinion of its obsolteness
> >    isn't so important.  I'll let Sue comment on this.
> > 
> > Suggested changes:
> > 
> > Current techniques that serve as an alternative to full mesh routing
> > include BGP Route Reflectors [2] and BGP Confederations [3].
> > 
> > Do [2] and [3] need to be made Normative references in this document?
> > 
> 
> I do not think that the language refering to multiple AS numbers 
> should be removed.  My suggestion is to broaden it, as there are/have 
> been networks that use public AS numbers as well as private ones to 
> divide the network into chunks, either as a long term design or for a 
> shorter term during transitional periods such as network integrations.

Please let's keep the scope of this document in mind - the scope
is to document why rfc1863 should be moved to historic. It is *not*
within the scope of *this* document to describe various alternatives 
to full I-BGP mesh.

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA12040 for <[e-mail]>; Mon, 24 May 2004 19:36:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSOt6-0000P7-4h; Mon, 24 May 2004 19:29:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSOoD-0008T1-Cy for [e-mail]; Mon, 24 May 2004 19:24:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16133 for <[e-mail]>; Mon, 24 May 2004 19:24:39 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSOoB-0000FW-V2 for [e-mail]; Mon, 24 May 2004 19:24:39 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSOnL-00008W-00 for [e-mail]; Mon, 24 May 2004 19:23:48 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BSOmQ-0007ji-00 for [e-mail]; Mon, 24 May 2004 19:22:50 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4ONMKBm046250; Mon, 24 May 2004 16:22:20 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4ONMKJ20172; Mon, 24 May 2004 16:22:20 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd) 
In-Reply-To: Your message of "Mon, 24 May 2004 10:56:59 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 24 May 2004 16:22:20 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Cc: [e-mail], Pekka Savola <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Jeffrey,

> I support the adoption of this.  It should go quickly.
> 
> I suggest a few changes though:
> 
> :   In the modern terminology, the term "route server" refers to a
> :   designated, normal BGP speaker set up for specific purposes such as
> :   data collection or retrieval; such route servers do not implement RFC
> :   1863.  For clarity, in the context of this document the term "RFC
> :   1863 route server" is used to refer to a route server as specified in
> :   RFC 1863.
> 
> In "modern teminology", route servers are actually route servers in
> the traditional proxy routing sense.  The current route collectors have,
> IMO, co-opted the term.  So, I'd suggest something along these lines:
> 
> By common usage, a "route server" can refer to one of two things:
> A "routing proxy" such as that used in the early NSF-Net at the
> NAPs or a "route collector" which is used for routing data collection
> and retrieval.  The latter case is also called a "looking glass".
> 
> Neither form of these route servers had implemented RFC 1863.  
> 
> For clarity, in the context of this document, the term "RFC 1863
> route server" is used to refer to a route server as specified in RFC 1863.

<WG co-chair hat off>

Let's keep in mind that the purpose of this document is to
move rfc1863 to historic, and *not* to describe the various uses
of the term "route server" (this is not to say that describing
various uses of the term "route server" is useless, it is just
that it is outside the scope of *this* document).

With this in mind how about replacing:

   In the modern terminology, the term "route server" refers to a
   designated, normal BGP speaker set up for specific purposes such as
   data collection or retrieval; such route servers do not implement RFC
   1863.  For clarity, in the context of this document the term "RFC
   1863 route server" is used to refer to a route server as specified in
   RFC 1863.

with the following:

   In the context of this document the term "RFC 1863 route server"
   is used to refer to a route server as specified in RFC1863.
   Other uses of the term "route server" are outside the scope
   of this document.

> :    Implementations of RFC 1863 route servers do not exist, and are not
> :    used as an alternative to full mesh routing.  Therefore the RFC 1863
> :    route server concept is considered extinct and RFC 1863 is requested
> :    to be moved to Historic status.
> 
> If something is extinct, should it not have lived before?  
> 
> Minor tweaks suggested:
> 
> Implementations of RFC 1863 route servers do not exist and are not
> used as an alternative to full mesh routing.  Therefore RFC 1863
> is requested to be moved to Historic status.
> 
> :   The most common technique as an alternative to full mesh routing is
> :   to use BGP route reflectors [2].  Conferedations [3] and/or dividing
> :   the autonomous system to multiple private AS numbers have also been
> :   used.  IDRP itself has never been standardized by the IETF and can be
> :   considered obsolete.
> 
> Two comments here aside from some punctuation suggestions:
> 1. Do people typically deploy private AS's outside of a confederation
>    context?
> 2. While IDRP never made it as an IETF specification, I believe it is
>    still a valid ISO specification and thus our opinion of its obsolteness
>    isn't so important.  I'll let Sue comment on this.

Either this, or instead of "IDRP itself" say "IDRP for IP".

> Suggested changes:
> 
> Current techniques that serve as an alternative to full mesh routing
> include BGP Route Reflectors [2] and BGP Confederations [3].

I like this change. 
  
> Do [2] and [3] need to be made Normative references in this document?

I don't think so.

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA00889 for <[e-mail]>; Mon, 24 May 2004 17:10:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSMi8-0004uU-Kz; Mon, 24 May 2004 17:10:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSMi6-0004u0-OT for [e-mail]; Mon, 24 May 2004 17:10:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01238 for <[e-mail]>; Mon, 24 May 2004 17:10:11 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSMi5-0006S0-49 for [e-mail]; Mon, 24 May 2004 17:10:13 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSMIB-0003jx-00 for [e-mail]; Mon, 24 May 2004 16:43:28 -0400
Received: from medusa.appliedtheory.com ([204.168.65.3] helo=navisite.com) by ietf-mx with esmtp (Exim 4.12) id 1BSLRR-0000V1-00 for [e-mail]; Mon, 24 May 2004 15:48:57 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Idr] proposed additional text
Date: Mon, 24 May 2004 15:48:27 -0400
Message-ID: <[e-mail]>
Thread-Topic: [Idr] proposed additional text
Thread-Index: AcRBoK24hiVOsjgpRH+C/FUYEsMdIgAJXmyA
From: "Looney, Jonathan" <[e-mail]>
To: <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id RAA00889

>    However, absent a standard mechanism for effecting
>    such changes in a coordinated fashion between peers, one cannot
>    assume that BGP-4 implementations complying with this RFC will
>    support frequent key changes.

I think this sentence should be reworded and/or removed.  I believe that
this limitation is an operational one, rather than being a limit of a
BGP implementation.  Every BGP implementation of which I'm aware will
(as it should) let you change keys whenever you want; the difficulty is
in coordinating with peers.

-Jon

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA29700 for <[e-mail]>; Mon, 24 May 2004 16:56:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSMUR-0003Gt-76; Mon, 24 May 2004 16:56:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSMUQ-0003Gl-6i for [e-mail]; Mon, 24 May 2004 16:56:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28935 for <[e-mail]>; Mon, 24 May 2004 16:56:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSMUO-0005KW-U6 for [e-mail]; Mon, 24 May 2004 16:56:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSM9M-0002R7-00 for [e-mail]; Mon, 24 May 2004 16:34:22 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BSKFU-0007nM-00 for [e-mail]; Mon, 24 May 2004 14:32:32 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4OIUW0N039736; Mon, 24 May 2004 14:30:32 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Andrew Lee <[e-mail]>
Subject: Re: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd) 
In-reply-to: Your message of "Mon, 24 May 2004 10:41:38 CDT." <[e-mail]> 
Date: Mon, 24 May 2004 14:30:32 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>, Andrew Lee writes:
> 
> > :   The most common technique as an alternative to full mesh routing is
> > :   to use BGP route reflectors [2].  Conferedations [3] and/or dividing
> > :   the autonomous system to multiple private AS numbers have also been
> > :   used.  IDRP itself has never been standardized by the IETF and can be
> > :   considered obsolete.
> > 
> > Two comments here aside from some punctuation suggestions:
> > 1. Do people typically deploy private AS's outside of a confederation
> >    context?


The NSFNET had about 20 public AS numbers just in the NSFNET T3
backbone alone.

Confederations and private AS removed the need to do that sort of
thing.

For a long time UUNET had 701 and 702 (Europe) and other providers had
multiple AS.

I'm not sure if any have multiple AS other than those that use
confederations these days.

It is worth noting that those that use confederations typically use
both confederations and route reflectors within the confederations to
make really big networks scale better.  Aggregation is done at
confederation boundaries (a scaling consideration).

> > 2. While IDRP never made it as an IETF specification, I believe it is
> >    still a valid ISO specification and thus our opinion of its obsolteness
> >    isn't so important.  I'll let Sue comment on this.
> > 
> > Suggested changes:
> > 
> > Current techniques that serve as an alternative to full mesh routing
> > include BGP Route Reflectors [2] and BGP Confederations [3].
> > 
> > Do [2] and [3] need to be made Normative references in this document?
> > 
> 
> I do not think that the language refering to multiple AS numbers 
> should be removed.  My suggestion is to broaden it, as there are/have 
> been networks that use public AS numbers as well as private ones to 
> divide the network into chunks, either as a long term design or for a 
> shorter term during transitional periods such as network integrations.

We are talking about the Internet and use of IDRP in IP.  IDRP is
about as alive as CLNP in the Internet (completely dead and not even
discussed anymore).  This may be important to anyone reading IDR
archives of 8-10 years ago when BGP5 == IDRP was commonly stated.

Curtis

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


Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA12021 for <[e-mail]>; Mon, 24 May 2004 12:56:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSIJ2-0005tm-Fy; Mon, 24 May 2004 12:28:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSI82-0003Ni-0y for [e-mail]; Mon, 24 May 2004 12:16:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17403 for <[e-mail]>; Mon, 24 May 2004 12:16:38 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSI80-0003bZ-L3 for [e-mail]; Mon, 24 May 2004 12:16:40 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSI7B-0003Vg-00 for [e-mail]; Mon, 24 May 2004 12:15:49 -0400
Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1BSI6f-0003Ov-00 for [e-mail]; Mon, 24 May 2004 12:15:17 -0400
Received: by newdev.harvard.edu (Postfix, from userid 501) id D6BA1214E7D; Mon, 24 May 2004 12:14:47 -0400 (EDT)
To: [e-mail]
Subject: Re: Re: [Idr] proposed additional text
Message-Id: <[e-mail]>
From: [e-mail] (Scott Bradner)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 24 May 2004 12:14:47 -0400 (EDT)

> On Mon, May 24, 2004 at 07:32:55AM -0700, Yakov Rekhter wrote:
> > Steve Kent proposed the following replacement for the text he suggested
> > earlier (the text I posted on 5/17/2004). 

as is normally the case with Steve's text, this text is clear and precise
and seems to say what needs to be said

Scott


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA09436 for <[e-mail]>; Mon, 24 May 2004 12:26:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSI5R-0002hd-SB; Mon, 24 May 2004 12:14:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHjX-00071k-8X for [e-mail]; Mon, 24 May 2004 11:51:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15830 for <[e-mail]>; Mon, 24 May 2004 11:51:19 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSHjV-0000xM-Vr for [e-mail]; Mon, 24 May 2004 11:51:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSHie-0000sa-00 for [e-mail]; Mon, 24 May 2004 11:50:29 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BSHi2-0000lq-00 for [e-mail]; Mon, 24 May 2004 11:49:50 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4OFnJ983011 for <[e-mail]>; Mon, 24 May 2004 08:49:19 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4OFnEJ55417 for <[e-mail]>; Mon, 24 May 2004 08:49:14 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] draft-ietf-idr-rfc3065bis-02.txt to Draft Standard
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 24 May 2004 08:49:14 -0700

Folks,

This is to start the IDR WG Last Call on advancing
draft-ietf-idr-rfc3065bis-02.txt to Draft Standard.

During the Last Call it would be greatly appreciated if folks would
read the document and comment on it to the IDR mailing list. In
other words, we need "yes, looks good" or "should fix this and
that", not just silence.

The deadline for comments is June 7, 2004.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA08701 for <[e-mail]>; Mon, 24 May 2004 12:16:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHlI-0007kS-5L; Mon, 24 May 2004 11:53:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHdF-0005r5-Fb for [e-mail]; Mon, 24 May 2004 11:44:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15446 for <[e-mail]>; Mon, 24 May 2004 11:44:50 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSHdE-0000JF-6z for [e-mail]; Mon, 24 May 2004 11:44:52 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSHcM-0000Ar-00 for [e-mail]; Mon, 24 May 2004 11:43:59 -0400
Received: from paintbird.ucs.indiana.edu ([156.56.103.100]) by ietf-mx with esmtp (Exim 4.12) id 1BSHb8-0007iv-00 for [e-mail]; Mon, 24 May 2004 11:42:42 -0400
Received: from [129.79.18.43] (d-18-43.dhcp-129-79.indiana.edu [129.79.18.43]) (authenticated bits=0) by paintbird.ucs.indiana.edu (8.12.11/8.12.10) with ESMTP id i4OFgBrw013036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 24 May 2004 10:42:12 -0500
Message-ID: <[e-mail]>
From: Andrew Lee <[e-mail]>
User-Agent: Mozilla Thunderbird 0.6 (Macintosh/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 24 May 2004 10:41:38 -0500

> :   The most common technique as an alternative to full mesh routing is
> :   to use BGP route reflectors [2].  Conferedations [3] and/or dividing
> :   the autonomous system to multiple private AS numbers have also been
> :   used.  IDRP itself has never been standardized by the IETF and can be
> :   considered obsolete.
> 
> Two comments here aside from some punctuation suggestions:
> 1. Do people typically deploy private AS's outside of a confederation
>    context?
> 2. While IDRP never made it as an IETF specification, I believe it is
>    still a valid ISO specification and thus our opinion of its obsolteness
>    isn't so important.  I'll let Sue comment on this.
> 
> Suggested changes:
> 
> Current techniques that serve as an alternative to full mesh routing
> include BGP Route Reflectors [2] and BGP Confederations [3].
> 
> Do [2] and [3] need to be made Normative references in this document?
> 

I do not think that the language refering to multiple AS numbers 
should be removed.  My suggestion is to broaden it, as there are/have 
been networks that use public AS numbers as well as private ones to 
divide the network into chunks, either as a long term design or for a 
shorter term during transitional periods such as network integrations.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA08143 for <[e-mail]>; Mon, 24 May 2004 12:10:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHjL-0006wc-Rq; Mon, 24 May 2004 11:51:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHPB-0001z8-1T for [e-mail]; Mon, 24 May 2004 11:30:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13980 for <[e-mail]>; Mon, 24 May 2004 11:30:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSHPA-0006ES-37 for [e-mail]; Mon, 24 May 2004 11:30:20 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSHOJ-00068l-00 for [e-mail]; Mon, 24 May 2004 11:29:27 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BSHNO-0005xV-00 for [e-mail]; Mon, 24 May 2004 11:28:30 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4OFS0982931; Mon, 24 May 2004 08:28:00 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4OFRtJ52894; Mon, 24 May 2004 08:27:55 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
cc: [e-mail]
Subject: Re: [Idr] proposed additional text 
In-Reply-To: Your message of "Mon, 24 May 2004 11:23:36 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 24 May 2004 08:27:55 -0700

Jeff,

> On Mon, May 24, 2004 at 07:32:55AM -0700, Yakov Rekhter wrote:
> > Steve Kent proposed the following replacement for the text he suggested
> > earlier (the text I posted on 5/17/2004). 
> [...]
> 
> > Please review and comment. The deadline for comments is 6/2/2004.
> 
> Aside from the English being a bit stylistically different than the
> rest of the document, I find no objections to this text.  All of my
> prior concerns are addressed within here.

Great !!!

> I'm also presuming the new references will be propagated to the BGP draft.

Certainly.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA07635 for <[e-mail]>; Mon, 24 May 2004 12:04:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHjC-0006uB-Kz; Mon, 24 May 2004 11:51:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHLJ-00018r-HL for [e-mail]; Mon, 24 May 2004 11:26:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13718 for <[e-mail]>; Mon, 24 May 2004 11:26:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSHLI-0005lS-Ea for [e-mail]; Mon, 24 May 2004 11:26:20 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSHKJ-0005fM-00 for [e-mail]; Mon, 24 May 2004 11:25:19 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BSHJK-0005Vt-00 for [e-mail]; Mon, 24 May 2004 11:24:18 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 1B54B2D4830; Mon, 24 May 2004 11:23:48 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07725-01-36; Mon, 24 May 2004 11:23:36 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C85502D481C; Mon, 24 May 2004 11:23:36 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i4OFNaw12968; Mon, 24 May 2004 11:23:36 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] proposed additional text
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 24 May 2004 11:23:36 -0400

On Mon, May 24, 2004 at 07:32:55AM -0700, Yakov Rekhter wrote:
> Steve Kent proposed the following replacement for the text he suggested
> earlier (the text I posted on 5/17/2004). 
[...]

> Please review and comment. The deadline for comments is 6/2/2004.

Aside from the English being a bit stylistically different than the
rest of the document, I find no objections to this text.  All of my
prior concerns are addressed within here.

I'm also presuming the new references will be propagated to the BGP draft.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA06787 for <[e-mail]>; Mon, 24 May 2004 11:54:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHdQ-0005sb-DS; Mon, 24 May 2004 11:45:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHD0-0008Ga-RD for [e-mail]; Mon, 24 May 2004 11:17:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13200 for <[e-mail]>; Mon, 24 May 2004 11:17:44 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSHCz-0004yZ-RA for [e-mail]; Mon, 24 May 2004 11:17:45 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSHBv-0004rf-00 for [e-mail]; Mon, 24 May 2004 11:16:40 -0400
Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1BSHBE-0004iE-00 for [e-mail]; Mon, 24 May 2004 11:15:56 -0400
Received: by newdev.harvard.edu (Postfix, from userid 501) id A8C2E214C16; Mon, 24 May 2004 11:15:00 -0400 (EDT)
To: [e-mail], [e-mail]
Subject: Re: [Idr] draft-savola-idr-rfc1863-historic-00.txt to Informational
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
From: [e-mail] (Scott Bradner)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 24 May 2004 11:15:00 -0400 (EDT)

> This is to start the IDR WG Last Call on making
> draft-savola-idr-rfc1863-historic-00.txt an IDR WG document
> and advancing this document to an Informational RFC.

I'd reword the abstract and title of section 1 to not be a requst
(since it will not be a request when it gets published as a RFC)

here is an example of what I mean (from RFC 1923)
Abstract

   RIP Version 1 [RFC-1058] has been declared an historic document.
   This Applicability statement provides the supporting motivation for
   that declaration.  The primary reason, as described below, is the
   Classful nature of RIPv1.


Scott

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA05885 for <[e-mail]>; Mon, 24 May 2004 11:44:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHCJ-0008D7-QY; Mon, 24 May 2004 11:17:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSH4w-00078s-0C for [e-mail]; Mon, 24 May 2004 11:09:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12753 for <[e-mail]>; Mon, 24 May 2004 11:09:21 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSH4t-0004K7-Cl for [e-mail]; Mon, 24 May 2004 11:09:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSH45-0004G1-00 for [e-mail]; Mon, 24 May 2004 11:08:33 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BSH3E-000460-00 for [e-mail]; Mon, 24 May 2004 11:07:40 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4OF79982873 for <[e-mail]>; Mon, 24 May 2004 08:07:09 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4OF74J50811 for <[e-mail]>; Mon, 24 May 2004 08:07:04 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] extending deadline for pref-limit comments
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 24 May 2004 08:07:04 -0700

Folks,

As requested by authors of both of the proposals on the table,
we are going to extend the deadline for comments for another
2 weeks (until Jun 7). 

To remind, the questions on the table are the following:

1. whether to take signalled prefix limit as a WG item

2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR
   WG document

3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR
   WG document

In your e-mails please *clearly* indicate your preferences. Providing
rationale for your preferences would be extremely useful as well.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03653 for <[e-mail]>; Mon, 24 May 2004 11:16:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSH2a-0006Wi-Ub; Mon, 24 May 2004 11:07:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGvE-0004tv-Ad for [e-mail]; Mon, 24 May 2004 10:59:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11881 for <[e-mail]>; Mon, 24 May 2004 10:59:19 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSGvB-0003Id-Qe for [e-mail]; Mon, 24 May 2004 10:59:21 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSGuJ-0003EN-00 for [e-mail]; Mon, 24 May 2004 10:58:28 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BSGtZ-00037M-00 for [e-mail]; Mon, 24 May 2004 10:57:41 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 662802D4862; Mon, 24 May 2004 10:57:11 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06296-01-64; Mon, 24 May 2004 10:56:59 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E95B12D4848; Mon, 24 May 2004 10:56:59 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i4OEux612233; Mon, 24 May 2004 10:56:59 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Pekka Savola <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd)
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 24 May 2004 10:56:59 -0400

I support the adoption of this.  It should go quickly.

I suggest a few changes though:

:   In the modern terminology, the term "route server" refers to a
:   designated, normal BGP speaker set up for specific purposes such as
:   data collection or retrieval; such route servers do not implement RFC
:   1863.  For clarity, in the context of this document the term "RFC
:   1863 route server" is used to refer to a route server as specified in
:   RFC 1863.

In "modern teminology", route servers are actually route servers in
the traditional proxy routing sense.  The current route collectors have,
IMO, co-opted the term.  So, I'd suggest something along these lines:

By common usage, a "route server" can refer to one of two things:
A "routing proxy" such as that used in the early NSF-Net at the
NAPs or a "route collector" which is used for routing data collection
and retrieval.  The latter case is also called a "looking glass".

Neither form of these route servers had implemented RFC 1863.  

For clarity, in the context of this document, the term "RFC 1863
route server" is used to refer to a route server as specified in RFC 1863.

:    Implementations of RFC 1863 route servers do not exist, and are not
:    used as an alternative to full mesh routing.  Therefore the RFC 1863
:    route server concept is considered extinct and RFC 1863 is requested
:    to be moved to Historic status.

If something is extinct, should it not have lived before?  

Minor tweaks suggested:

Implementations of RFC 1863 route servers do not exist and are not
used as an alternative to full mesh routing.  Therefore RFC 1863
is requested to be moved to Historic status.

:   The most common technique as an alternative to full mesh routing is
:   to use BGP route reflectors [2].  Conferedations [3] and/or dividing
:   the autonomous system to multiple private AS numbers have also been
:   used.  IDRP itself has never been standardized by the IETF and can be
:   considered obsolete.

Two comments here aside from some punctuation suggestions:
1. Do people typically deploy private AS's outside of a confederation
   context?
2. While IDRP never made it as an IETF specification, I believe it is
   still a valid ISO specification and thus our opinion of its obsolteness
   isn't so important.  I'll let Sue comment on this.

Suggested changes:

Current techniques that serve as an alternative to full mesh routing
include BGP Route Reflectors [2] and BGP Confederations [3].

Do [2] and [3] need to be made Normative references in this document?

Additionally (Danny), RFC 3065-bis needs to make sure RFC 1863 is used
as an Informative Reference.

If the updates to RFC 2796 and 3065 get published after this, we should
make sure they reference this memo.


-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02833 for <[e-mail]>; Mon, 24 May 2004 11:06:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGvx-000531-H5; Mon, 24 May 2004 11:00:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGXz-0001R9-BP for [e-mail]; Mon, 24 May 2004 10:35:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10508 for <[e-mail]>; Mon, 24 May 2004 10:35:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSGXw-0001ci-HG for [e-mail]; Mon, 24 May 2004 10:35:20 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSGX3-0001Xl-00 for [e-mail]; Mon, 24 May 2004 10:34:26 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BSGW5-0001OW-00 for [e-mail]; Mon, 24 May 2004 10:33:25 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4OEWtBm044385 for <[e-mail]>; Mon, 24 May 2004 07:32:55 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4OEWtJ47047 for <[e-mail]>; Mon, 24 May 2004 07:32:55 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: [Idr] proposed additional text
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 24 May 2004 07:32:55 -0700

Folks,

Steve Kent proposed the following replacement for the text he suggested
earlier (the text I posted on 5/17/2004). 

   BGP makes use of TCP for reliable transport of its traffic between
   peer routers. To provide connection-oriented integrity and data
   origin authentication, on a point-to-point basis, BGP specifies
   use of the mechanism defined in RFC 2385. These services are intended
   to detect and reject active wiretapping attacks against the
   inter-router TCP connections. Absent use of mechanisms that effect
   these security services, attackers can disrupt these TCP connections
   and/or masquerade as a legitimate peer router. Because the mechanism
   defined in the RFC does not provide peer-entity authentication,
   these connections may be subject to some forms of replay attacks
   that will not be detected at the TCP layer. Such attacks might
   result in delivery (from TCP) of "broken" or "spoofed" BGP messages.
   
   The mechanism defined in RFC 2385 augments the normal TCP checksum
   with a 16-byte message authentication code (MAC) that is computed
   over the same data as the TCP checksum. This MAC is based on a
   one-way hash function (MD5) and use of a secret key. The key is
   shared between peer routers and is used to generate MAC values that
   are not readily computed by an attacker who does not have access
   to the key. A compliant implementation must support this mechanism,
   and must allow a network administrator to activate it on a per-peer
   basis.
   
   RFC 2385 does not specify a means of managing (e.g., generating,
   distributing, and replacing) the keys used to compute the MAC. RFC
   3562 (an informational document) provides some guidance in this
   area, and provides rationale to support this guidance. It notes
   that a distinct key should be used for communication with each
   protected peer. If the same key is used for multiple peers, the
   offered security services may be degraded, e.g., due to increased
   risk of compromise at one router adversely affecting other routers.
   
   The keys used for MAC computation should be changed periodically,
   to minimize the impact of a key compromise or successful cryptanalytic
   attack. RFC 3562 suggest a crypto period (the interval during which
   a key is employed) of at most 90 days. More frequent key changes
   reduce the likelihood that replay attacks (as described above) will
   be feasible. However, absent a standard mechanism for effecting
   such changes in a coordinated fashion between peers, one cannot
   assume that BGP-4 implementations complying with this RFC will
   support frequent key changes.
   
   Obviously, each  key also should be chosen so as to be hard for an
   attacker to guess.  The techniques specified in RFC 1750 for random
   number generation provide a guide for generation of values that
   could be used as keys. RFC 2385 calls for implementations to support
   keys "composed of a string of printable ASCII of 80 bytes or less."
   RFC 3562 suggests keys used in this context be 12 to 24 bytes
   of random (pseudo-random) bits. This is fairly consistent with
   suggestions for analogous MAC algorithms, which typically employ
   keys in the range of 16-20 bytes. RFC 3562 also observes that, to
   provide enough random bits at the low end of this range, a typical
   ACSII text string would have to be close to the upper bound for
   key length specified in RFC 2385.


Please review and comment. The deadline for comments is 6/2/2004.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA29999 for <[e-mail]>; Mon, 24 May 2004 10:32:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGJH-0007XL-LT; Mon, 24 May 2004 10:20:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSG7p-0005nS-E8 for [e-mail]; Mon, 24 May 2004 10:08:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07843 for <[e-mail]>; Mon, 24 May 2004 10:08:17 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSG7n-0007GF-38 for [e-mail]; Mon, 24 May 2004 10:08:19 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSG6u-0007E4-00 for [e-mail]; Mon, 24 May 2004 10:07:25 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BSG6R-0007AT-00 for [e-mail]; Mon, 24 May 2004 10:06:55 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4OE6OBm044281 for <[e-mail]>; Mon, 24 May 2004 07:06:25 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4OE6OJ44608 for <[e-mail]>; Mon, 24 May 2004 07:06:24 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] draft-savola-idr-rfc1863-historic-00.txt to Informational
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 24 May 2004 07:06:24 -0700

Folks,

This is to start the IDR WG Last Call on making
draft-savola-idr-rfc1863-historic-00.txt an IDR WG document
and advancing this document to an Informational RFC.

The Last Call ends June 7.

Sue & Yakov.

P.S. Please note that there is a consensus in the IDR WG to
move rfc1863 to Historic.
------- Forwarded Message

Date:    Fri, 21 May 2004 07:21:37 +0300
From:    Pekka Savola <[e-mail]>
To:      [e-mail]
Subject: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd)

FYI --

As there seemed to be consensus for moving RFC 1863 to historic, I 
made a short I-D to document it.

Comments, adoption as WG doc, ...?

- ---------- Forwarded message ----------
Date: Thu, 20 May 2004 16:01:08 -0400
From: [e-mail]
To: [e-mail]
Subject: I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt

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


	Title		: Request to Move RFC 1863 to Historic
	Author(s)	: P. Savola
	Filename	: draft-savola-idr-rfc1863-historic-00.txt
	Pages		: 4
	Date		: 2004-5-20
	
This memo requests moving RFC 1863, A BGP/IDRP Route Server"M
alternative to a full mesh routing, to Historic status.  This memo"M
also Obsoletes RFC 1863.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-savola-idr-rfc1863-historic-00.txt


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

------- End of Forwarded Message


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA18754 for <[e-mail]>; Sat, 22 May 2004 11:26:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRYDT-0002ii-8s; Sat, 22 May 2004 11:15:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRYBf-0001k4-UZ for [e-mail]; Sat, 22 May 2004 11:13:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12776 for <[e-mail]>; Sat, 22 May 2004 11:13:21 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRYBf-0001Qp-3e for [e-mail]; Sat, 22 May 2004 11:13:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRYAm-0001HU-00 for [e-mail]; Sat, 22 May 2004 11:12:29 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BRYAR-00017Y-00 for [e-mail]; Sat, 22 May 2004 11:12:07 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4B0D02D4897 for <[e-mail]>; Sat, 22 May 2004 11:11:37 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 40387-02-3 for <[e-mail]>; Sat, 22 May 2004 11:11:24 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C1BCE2D4843 for <[e-mail]>; Sat, 22 May 2004 11:11:24 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-00.txt
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-00.txt
Thread-Index: AcQ/nRx7a6BlEglsTLeNIvc53o2LfwAXr6cg
From: "Susan Hares" <[e-mail]>
To: "Alex Zinin" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Sat, 22 May 2004 11:11:24 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA18754

Alex:


Thanks for the input. Here's the new text, please
comment:  
 
This revision of the BGP-4 standard [BGP4] updates the BGP standard [RFC1771] to be in alignment with the deployments of the BGP-4 protocols.   Appendix A of [BGP4] lists the differences between [RFC1771] and this BGP standard.  BGP-4 as deployed in the Internet encompasses both this base specification and additional specifications such as TCP MD5 [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations   [RFC3065], and BGP Route Refresh [RFC 2918].  

BGP as a widely deployed cornerstone of Internet technology continues to add additional functionality as the needs within the Internet require. This survey had 259 detailed questions on the compliances with the standard.  4 implementers (Alcatel, Cisco, Laurel, NextHop) sent in implementation reports.  Section 2 provides a compilation of those results.

Section 1.3 provides the quick survey results on inter-operability. Section 1.4 provides an inter-operability of the 4 implementations.
 
Due to the large number of BGP implementations and the small number of responses, the editor took an informal survey to determine if the length of survey was an issue.  The survey questions and the results are listed in section 1.5.  X additional implementers who responded below indicating inter-operability with other implementations.  Of these X implementations, Y also indicated the length of the survey was as problem. The editor recommends that other methods, such as enlisting existing testing vendors be employed to gather more implementation report.

The editor has compiled the survey results and does guarantee the accuracy of the responses.

Sue

-----Original Message-----
From: Alex Zinin [mailto:[e-mail]]
Sent: Friday, May 21, 2004 9:36 PM
To: Susan Hares
Cc: [e-mail]
Subject: Re: [Idr] AD-review comments on
draft-ietf-idr-bgp-implementation-00.txt


Sue,

 On the 2119 part, something along these lines--

    For every item listed, the respondents indicated whether their
    implementation supports the Functionality/Description or not (Y/N)
    indicated by the RFC2119 [3] language.

 --would seem better to me (the old texts read as "supports... according to the
 RFC 2119", the proposed reads "Functionality/Decription ... indicated by the
 RFC 2119"). A rather minor point, really.

 Thanks.

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

Tuesday, May 4, 2004, 10:45:41 AM, Susan Hares wrote:
> Alex:

> I'm catching up with old mail that I didn't respond to:

> 	On section 1 - oops, I'll fix that to match the draft
> 	On section 1.2 - oops, will fix tonight.
> 	On section 1.4 - I've got to query the implementers. 
> 	On section 1.5.2 - I'll query Laurel.
	
> 	RFC 2119 - we need to at least note that that was the context
> 		     of the messages.  Could you send text that you'd like
> 			that indicates that message. 

> Thanks for all the great comments.

> Sue
 
> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Wednesday, April 14, 2004 10:42 PM
> To: [e-mail]
> Subject: [Idr] AD-review comments on
> draft-ietf-idr-bgp-implementation-00.txt


> Seems like this is out of context.

>>     RFC 1771 in alignment with the deployments of the BGP-4 protocols.   
>>     The changes with RFC 1771 are listed in the appendix A of[BGP4].   
>>     BGP-4 as deployed in the Internet encompasses both this base 
>>     specification and additional specifications such as TCP MD5 
>>     [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations   
>>     [RFC3065], and BGP Route Refresh [RFC 2918].  
>>             
>>     BGP as a widely deployed cornerstone of Internet technology 
>>     continues to add additional functionality as the needs within the 
>>     Internet require. This survey had 259 detailed questions on the 
>>     compliances with the standard.  3 implementers (Cisco, Laurel, 
>>     NextHop) sent in implementation reports.  Sections X - Y provides 
>>     the compilation of those results. 
>> 

> [snip] 
      
>>     X implementers who responded below indicating inter-operability with 
>>     other implementations.  Of these X implementations, Y also indicated 
>>     the length of the survey was as problem. The editor recommends that 
>>     other methods, such as enlisting existing testing vendors be 
>>     employed to gather more implementation report. 
>>      
>>     Section Z provides the quick survey results on inter-operability.  
>>     
>>  
>>  
>> Hares & Retana          Expires - August 2004                [Page 3] 
>> 
>> 
>> 
>> 
>>                  draft-ietf-idr-bgp-implementation-00    February 2004 
>>  
>>  

> X, Y, and Z need to be filled out... ;)

>> 1.2 Full Survey result summary 
>>      
>>     Significant Differences 
>>       
>>     All 259 survey points had two "y" or "y" and "O" except the 
>>     following: 

> At this point of the document, it is not clear what "y" and "0" are.

>>       

> Generally, if we don't have at least two implementations for a specific feature,
> it can't stay in the spec. The granularity of the BGP implementation report
> is finer than on a per-feature basis, but we still need to see if the spec needs
> to be fixed accordingly. More specific comments below:

>>       MUST - Question 214 
>>        
>>       Question 214 about aggregation of  routes. section 9.1.4 had a "N" 
>>       response from 3 implementers indicating that they install both 
>>       routes, and 1 yes. 

> when I look at section 2.43.214, I see:

>        Alcatel Y/N/O/Comments: Y
>        Cisco   Y/N/O/Comments: Y 
>        Laurel  Y/N/O/Comments: Y 
>        NextHop Y/N/O/Comments: Y 

> wrong section?

>>       SHALL NOT - Question 228, regarding section 9.2.2.2 
>>        
>>       Three vendors (Alcatel, Cisco, Laurel), answered "N" to shall not 
>>       (meaning they did).  One vendor (NextHop) indicate "y" matching 
>>       the specification. 
>>        
>>         text: Routes that have different MULTI_EXIT_DISC attribute SHALL 
>>         NOT be aggregated. 

> If this is considered to be important for protocol correctness, then the WG
> may consider softening the requirements language and changing it to "SHOULD
> NOT"--apparently some implementers found that under certain circumstances
> such routes still need to be aggregated.

>>       SHOULD - 2 in appendix F (questions 257, 258)
>>        
>>       Three vendors said no, one vendor said yes to question 257.  All 
>>       four vendors indicated no to question 258. (Please note that 
>>       Appendix F is an optional text section) 
>>         
>>        Text: section F.2 - A BGP speaker which needs to withdraw a 
>>        destination and send an update about a more specific or less  
>>        specific route SHOULD combine them into the same UPDATE message.  
>>         
>>        Text: Section F.6: The last instance (rightmost occurrence) of 
>>        that AS number is kept.

> Assuming that the appendices are not a normative part of the spec, the
> 2119 language should not be used there.

> ...
>> 1.4 Implementations and interoperability
>>     
>>    Short informal summary of implementers reporting implementations and 
>>    inter-operability 
>>      
>>      [This section will be added later but will have the format below ] 
>>
>>                     Alcatel Cisco Laurel  NextHop  
>>        Alcatel                                 
>>        Cisco                                   
>>        Laurel                                                   
>>        NextHop                                        

> the above table needs to be filled out.

>> 1.5 BGP Implementation Identification

> This section does not specify the origin of code

>>    1.5.0 Alcatel 
>>     
>>    1.5.1 Cisco 
>>    Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S 
>>    Date: 11/26/2003 
>>     
>>    1.5.2 Laurel 
>>     
>>    1.5.3 NextHop Technologies 
>>    Implementation Name/Version: Gated NGC 2.0, 2.2 
>>    Date: January 2004  
>>  
>>  
>> Hares & Retana          Expires - August 2004                [Page 5] 
>> 
>> 
>> 
>> 
>>                  draft-ietf-idr-bgp-implementation-00    February 2004 
>>  
>>  
>>     
>> 2. BGP4 Implementation Report 
>>     
>>    For every item listed, the respondents indicated whether their 
>>    implementation supports the Functionality/Description or not (Y/N) 
>>    according to the RFC2119 [3] language indicated.

> "according to the RFC 2119" should probably be removed. The implementation
> either decides to support something the 2119 language prescribes in some form or
> it doesn't.

>> Any respondent 
>>    comments are included.  If appropriate, the respondents indicated 
>>    with O the fact that the support is neither Y/N (an alternate 
>>    behavior, for example). Refer to the appropriate sections in the 
>>    latest BGP-4 ID [4] for additional details. 



> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA18558 for <[e-mail]>; Sat, 22 May 2004 11:24:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRYDR-0002iY-0Q; Sat, 22 May 2004 11:15:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRYAm-0001R5-0v for [e-mail]; Sat, 22 May 2004 11:12:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12756 for <[e-mail]>; Sat, 22 May 2004 11:12:25 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRYAl-0001HK-88 for [e-mail]; Sat, 22 May 2004 11:12:27 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRY9x-00017c-00 for [e-mail]; Sat, 22 May 2004 11:11:38 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BRY9S-0000xB-00 for [e-mail]; Sat, 22 May 2004 11:11:06 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E899C2D4873 for <[e-mail]>; Sat, 22 May 2004 11:10:35 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 40018-01-26 for <[e-mail]>; Sat, 22 May 2004 11:10:22 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9E6D92D4843 for <[e-mail]>; Sat, 22 May 2004 11:10:22 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] Inter-operable BGP implementations - Call for information 
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Inter-operable BGP implementations - Call for information 
Thread-Index: AcQ+ipLTiWgcThMaQFyPlnSVLHuNFQBfJfSA
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>, "Pekka Savola" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Sat, 22 May 2004 11:10:22 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA18558

Curtis: 

Thanks for sending out this note.

My motivation was to show that there are
a lot of inter-operable implementations --
but the survey was too long.

I am trying to take an informal survey
(no RFC 2119 binding) to find out of
those who have a BGP4 implementation
that matches draft-ietf-idr-bgp4-23.txt 
(shortly to be -24.txt)

1) Why did you not respond to the survey:
	a) length of survey
	b) other (please comment)
2) Do you interoperate with other BGP 
   implementations?

  If so, which bgp implementations?
 
For those that respond, I will need:
1) contact (email, name) if different than
   the person sending in the response.

2) implementation: product/revision
   and date of revision.

So...anyone else who wants to send
me this information, please send it 
within the next 2 weeks. 

Sue

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]]
Sent: Thursday, May 20, 2004 12:49 PM
To: Pekka Savola
Cc: Susan Hares; [e-mail]
Subject: Re: [Idr] Inter-operable BGP implementations - Call for
information 



In message <[e-mail]>, Pekka Savola 
writes:
> On Thu, 20 May 2004, Susan Hares wrote:
> > I am revising the BGP implementation survey, and
> > need an updated on inter-operable implementations.
> > I will accept input for 2 weeks ending 6/2/04.  
> > At that time, I will release version -01 of the BGP
> > implementation survey. 
> 
> FWIW, if you look at RFC2026, it's not sufficient that you have
> interoperable implementations (in general), there must be two
> interoperable implementations of _every feature_ of the spec.
> 
> >From 4.1.2,
>                                                             For the
>    purposes of this section, "interoperable" means to be functionally
>    equivalent or interchangeable components of the system or process in
>    which they are used.
> 
> The interpretation of what this means has been quite blur, but it 
> would be better that if interop tests explicitly tested each feature 
> of the spec, not the spec as a whole.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



Field experience has already proven many BGP implementations to be
interoperable by the definition above.  You can pull out a brand X
router and put in a brand Y router it all works fine, for a large set
of X and Y.

The spec has a lot of MUST and SHOULD and the first survey asked for
an answer for each one of them.  A lot of providers just didn't make
it through verifying which of the SHOULDs they needed to check off
before the cutoff for accepting these (which was just a few weeks).

I don't really know Sue's motivation for this latest request.

What might me useful would be to include the responses to the original
survey, add any that come in, and include the interoperability
experience (without full surveys) that Sue has asked for just as
further evidence that there are a lot of interoperable BGP
implementations.

We should be able to update the protocol experiences doc (if we want
to) after the whole set goes through six months or a year from now if
additional vendors come forward with completed surveys.

Curtis


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA09279 for <[e-mail]>; Sat, 22 May 2004 09:39:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRWZf-00070s-Mp; Sat, 22 May 2004 09:30:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRWQI-0004t4-SR for [e-mail]; Sat, 22 May 2004 09:20:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05664 for <[e-mail]>; Sat, 22 May 2004 09:20:19 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRWQH-00048o-5u for [e-mail]; Sat, 22 May 2004 09:20:21 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRWPM-0003zE-00 for [e-mail]; Sat, 22 May 2004 09:19:25 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BRWOv-0003pX-00 for [e-mail]; Sat, 22 May 2004 09:18:57 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E5C582D4873 for <[e-mail]>; Sat, 22 May 2004 09:18:26 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 37518-01-11 for <[e-mail]>; Sat, 22 May 2004 09:18:13 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9A1712D484F for <[e-mail]>; Sat, 22 May 2004 09:18:13 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] Inter-operable BGP implementations - Call for information 
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Inter-operable BGP implementations - Call for information 
Thread-Index: AcQ/xm73NTJ2y9zuTm6jzfGJxbhhFwANN1qQ
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>, "Pekka Savola" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Sat, 22 May 2004 09:18:13 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id JAA09279

Pekka and Curtis:

This is an information section for the IESG.

The implementation and inter-operability is
given by the 4 implementations that sent in the
questionnaire: Alcatel, Laurel, Cisco and NextHop.

I'd welcome any other implementation who'd
like to fill out the 259 questions.

sue

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]]
Sent: Saturday, May 22, 2004 2:30 AM
To: Pekka Savola
Cc: Susan Hares; [e-mail]
Subject: Re: [Idr] Inter-operable BGP implementations - Call for
information 



In message <[e-mail]>, Pekka Savola w
rites:
> On Fri, 21 May 2004, Susan Hares wrote:
> > All issues from RFC 2026 are covered
> > in that document. 
> 
> Not quite.  RFC2026 requires *both* implementation and
> interoperability of 'functionally equivalent or interchangeable
> components'.  The document just describes implementation in
> excruciating detail (good! :).
> 
> Even though implementations are known to interoperate in general, I 
> don't think anyone has made a question-by-question interoperability 
> test .. which, depending on how you interpret RFC2026 language, could 
> be required.


Sounds to me more like Corperation for Open Sytems (or or whatever
they were called) that the IETF.

I don't think we're going to arrive at any sort of provable
correctness.

Maybe we should look at what OSPF did.

Curtis

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA02931 for <[e-mail]>; Sat, 22 May 2004 02:49:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQ9v-00068f-N5; Sat, 22 May 2004 02:39:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQ4D-0004uW-1G for [e-mail]; Sat, 22 May 2004 02:33:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15284 for <[e-mail]>; Sat, 22 May 2004 02:33:05 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRQ49-0003m9-1b for [e-mail]; Sat, 22 May 2004 02:33:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRQ3J-0003dZ-00 for [e-mail]; Sat, 22 May 2004 02:32:14 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BRQ2S-0003VY-00 for [e-mail]; Sat, 22 May 2004 02:31:20 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4M6Tw0N021496; Sat, 22 May 2004 02:29:58 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pekka Savola <[e-mail]>
cc: Susan Hares <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] Inter-operable BGP implementations - Call for information 
In-reply-to: Your message of "Sat, 22 May 2004 04:01:42 +0300." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Sat, 22 May 2004 02:29:58 -0400

In message <[e-mail]>, Pekka Savola w
rites:
> On Fri, 21 May 2004, Susan Hares wrote:
> > All issues from RFC 2026 are covered
> > in that document. 
> 
> Not quite.  RFC2026 requires *both* implementation and
> interoperability of 'functionally equivalent or interchangeable
> components'.  The document just describes implementation in
> excruciating detail (good! :).
> 
> Even though implementations are known to interoperate in general, I 
> don't think anyone has made a question-by-question interoperability 
> test .. which, depending on how you interpret RFC2026 language, could 
> be required.


Sounds to me more like Corperation for Open Sytems (or or whatever
they were called) that the IETF.

I don't think we're going to arrive at any sort of provable
correctness.

Maybe we should look at what OSPF did.

Curtis

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA08429 for <[e-mail]>; Fri, 21 May 2004 21:50:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRLYR-0007Hg-LN; Fri, 21 May 2004 21:44:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRLRt-0005Y3-VM for [e-mail]; Fri, 21 May 2004 21:37:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18115 for <[e-mail]>; Fri, 21 May 2004 21:37:14 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRLRr-0007Dg-4L for [e-mail]; Fri, 21 May 2004 21:37:15 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRLQt-00076w-00 for [e-mail]; Fri, 21 May 2004 21:36:16 -0400
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BRLQF-0006y8-00 for [e-mail]; Fri, 21 May 2004 21:35:36 -0400
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRLQG-0008Ms-D9; Sat, 22 May 2004 01:35:36 +0000
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: "Susan Hares" <[e-mail]>
CC: [e-mail]
Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-00.txt
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME  autolearn=no version=2.60
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 21 May 2004 18:35:34 -0700

Sue,

 On the 2119 part, something along these lines--

    For every item listed, the respondents indicated whether their
    implementation supports the Functionality/Description or not (Y/N)
    indicated by the RFC2119 [3] language.

 --would seem better to me (the old texts read as "supports... according to the
 RFC 2119", the proposed reads "Functionality/Decription ... indicated by the
 RFC 2119"). A rather minor point, really.

 Thanks.

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

Tuesday, May 4, 2004, 10:45:41 AM, Susan Hares wrote:
> Alex:

> I'm catching up with old mail that I didn't respond to:

> 	On section 1 - oops, I'll fix that to match the draft
> 	On section 1.2 - oops, will fix tonight.
> 	On section 1.4 - I've got to query the implementers. 
> 	On section 1.5.2 - I'll query Laurel.
	
> 	RFC 2119 - we need to at least note that that was the context
> 		     of the messages.  Could you send text that you'd like
> 			that indicates that message. 

> Thanks for all the great comments.

> Sue
 
> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Wednesday, April 14, 2004 10:42 PM
> To: [e-mail]
> Subject: [Idr] AD-review comments on
> draft-ietf-idr-bgp-implementation-00.txt


> Seems like this is out of context.

>>     RFC 1771 in alignment with the deployments of the BGP-4 protocols.   
>>     The changes with RFC 1771 are listed in the appendix A of[BGP4].   
>>     BGP-4 as deployed in the Internet encompasses both this base 
>>     specification and additional specifications such as TCP MD5 
>>     [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations   
>>     [RFC3065], and BGP Route Refresh [RFC 2918].  
>>             
>>     BGP as a widely deployed cornerstone of Internet technology 
>>     continues to add additional functionality as the needs within the 
>>     Internet require. This survey had 259 detailed questions on the 
>>     compliances with the standard.  3 implementers (Cisco, Laurel, 
>>     NextHop) sent in implementation reports.  Sections X - Y provides 
>>     the compilation of those results. 
>> 

> [snip] 
      
>>     X implementers who responded below indicating inter-operability with 
>>     other implementations.  Of these X implementations, Y also indicated 
>>     the length of the survey was as problem. The editor recommends that 
>>     other methods, such as enlisting existing testing vendors be 
>>     employed to gather more implementation report. 
>>      
>>     Section Z provides the quick survey results on inter-operability.  
>>     
>>  
>>  
>> Hares & Retana          Expires - August 2004                [Page 3] 
>> 
>> 
>> 
>> 
>>                  draft-ietf-idr-bgp-implementation-00    February 2004 
>>  
>>  

> X, Y, and Z need to be filled out... ;)

>> 1.2 Full Survey result summary 
>>      
>>     Significant Differences 
>>       
>>     All 259 survey points had two "y" or "y" and "O" except the 
>>     following: 

> At this point of the document, it is not clear what "y" and "0" are.

>>       

> Generally, if we don't have at least two implementations for a specific feature,
> it can't stay in the spec. The granularity of the BGP implementation report
> is finer than on a per-feature basis, but we still need to see if the spec needs
> to be fixed accordingly. More specific comments below:

>>       MUST - Question 214 
>>        
>>       Question 214 about aggregation of  routes. section 9.1.4 had a "N" 
>>       response from 3 implementers indicating that they install both 
>>       routes, and 1 yes. 

> when I look at section 2.43.214, I see:

>        Alcatel Y/N/O/Comments: Y
>        Cisco   Y/N/O/Comments: Y 
>        Laurel  Y/N/O/Comments: Y 
>        NextHop Y/N/O/Comments: Y 

> wrong section?

>>       SHALL NOT - Question 228, regarding section 9.2.2.2 
>>        
>>       Three vendors (Alcatel, Cisco, Laurel), answered "N" to shall not 
>>       (meaning they did).  One vendor (NextHop) indicate "y" matching 
>>       the specification. 
>>        
>>         text: Routes that have different MULTI_EXIT_DISC attribute SHALL 
>>         NOT be aggregated. 

> If this is considered to be important for protocol correctness, then the WG
> may consider softening the requirements language and changing it to "SHOULD
> NOT"--apparently some implementers found that under certain circumstances
> such routes still need to be aggregated.

>>       SHOULD - 2 in appendix F (questions 257, 258)
>>        
>>       Three vendors said no, one vendor said yes to question 257.  All 
>>       four vendors indicated no to question 258. (Please note that 
>>       Appendix F is an optional text section) 
>>         
>>        Text: section F.2 - A BGP speaker which needs to withdraw a 
>>        destination and send an update about a more specific or less  
>>        specific route SHOULD combine them into the same UPDATE message.  
>>         
>>        Text: Section F.6: The last instance (rightmost occurrence) of 
>>        that AS number is kept.

> Assuming that the appendices are not a normative part of the spec, the
> 2119 language should not be used there.

> ...
>> 1.4 Implementations and interoperability
>>     
>>    Short informal summary of implementers reporting implementations and 
>>    inter-operability 
>>      
>>      [This section will be added later but will have the format below ] 
>>
>>                     Alcatel Cisco Laurel  NextHop  
>>        Alcatel                                 
>>        Cisco                                   
>>        Laurel                                                   
>>        NextHop                                        

> the above table needs to be filled out.

>> 1.5 BGP Implementation Identification

> This section does not specify the origin of code

>>    1.5.0 Alcatel 
>>     
>>    1.5.1 Cisco 
>>    Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S 
>>    Date: 11/26/2003 
>>     
>>    1.5.2 Laurel 
>>     
>>    1.5.3 NextHop Technologies 
>>    Implementation Name/Version: Gated NGC 2.0, 2.2 
>>    Date: January 2004  
>>  
>>  
>> Hares & Retana          Expires - August 2004                [Page 5] 
>> 
>> 
>> 
>> 
>>                  draft-ietf-idr-bgp-implementation-00    February 2004 
>>  
>>  
>>     
>> 2. BGP4 Implementation Report 
>>     
>>    For every item listed, the respondents indicated whether their 
>>    implementation supports the Functionality/Description or not (Y/N) 
>>    according to the RFC2119 [3] language indicated.

> "according to the RFC 2119" should probably be removed. The implementation
> either decides to support something the 2119 language prescribes in some form or
> it doesn't.

>> Any respondent 
>>    comments are included.  If appropriate, the respondents indicated 
>>    with O the fact that the support is neither Y/N (an alternate 
>>    behavior, for example). Refer to the appropriate sections in the 
>>    latest BGP-4 ID [4] for additional details. 



> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA07833 for <[e-mail]>; Fri, 21 May 2004 21:42:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRLLq-0004Vp-6y; Fri, 21 May 2004 21:31:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRLGs-0003UV-3S for [e-mail]; Fri, 21 May 2004 21:25:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17707 for <[e-mail]>; Fri, 21 May 2004 21:25:50 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRLGp-00066o-Cb for [e-mail]; Fri, 21 May 2004 21:25:51 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRLFy-00061m-00 for [e-mail]; Fri, 21 May 2004 21:24:59 -0400
Received: from mproxy.gmail.com ([216.239.56.253]) by ietf-mx with smtp (Exim 4.12) id 1BRLF7-0005w6-00 for [e-mail]; Fri, 21 May 2004 21:24:05 -0400
Received: by mproxy.gmail.com with SMTP id u33so70205cwc for <[e-mail]>; Fri, 21 May 2004 18:24:05 -0700 (PDT)
Received: by 10.11.100.25 with SMTP id x25mr182047cwb; Fri, 21 May 2004 18:24:05 -0700 (PDT)
Message-ID: <[e-mail]>
From: Vivek Menezes <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 21 May 2004 18:24:05 -0700

> Could you please clarify whether (a) you are in favor or against
> accepting signalled prefix limit as an IDR WG item, and if yes,

It appears that we are unnecessarily making the protocol more complex with
no added advantage. The right thing for a peer to do when it reaches it maximum
configured number of prefixes is to shutdown the session. I like the
idea (not necessarily
the proposal ) of supporting multiple BGP sessions, with each session
for a different protocol, so that different protocols do not disrupt
each others.

passing around a signal between peers that adds no value in their
decision process
is unnecessary.

The answer is "NO"

Vivek.

> then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
> or draft-keyur-prefixlimit-orf-00.txt) would you favor.

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA05838 for <[e-mail]>; Fri, 21 May 2004 21:19:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRL4P-0000lO-G9; Fri, 21 May 2004 21:13:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRKvb-0006Za-3B for [e-mail]; Fri, 21 May 2004 21:03:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16733 for <[e-mail]>; Fri, 21 May 2004 21:03:52 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRKvY-0003fh-IE for [e-mail]; Fri, 21 May 2004 21:03:52 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRKuc-0003aZ-00 for [e-mail]; Fri, 21 May 2004 21:02:54 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BRKu5-0003S4-00 for [e-mail]; Fri, 21 May 2004 21:02:21 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4M11gQ08428; Sat, 22 May 2004 04:01:43 +0300
From: Pekka Savola <[e-mail]>
To: Susan Hares <[e-mail]>
cc: [e-mail]
Subject: RE: [Idr] Inter-operable BGP implementations - Call for information
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Sat, 22 May 2004 04:01:42 +0300 (EEST)

On Fri, 21 May 2004, Susan Hares wrote:
> All issues from RFC 2026 are covered
> in that document. 

Not quite.  RFC2026 requires *both* implementation and
interoperability of 'functionally equivalent or interchangeable
components'.  The document just describes implementation in
excruciating detail (good! :).

Even though implementations are known to interoperate in general, I 
don't think anyone has made a question-by-question interoperability 
test .. which, depending on how you interpret RFC2026 language, could 
be required.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA00554 for <[e-mail]>; Fri, 21 May 2004 20:12:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJur-00021a-EW; Fri, 21 May 2004 19:59:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJpo-00013E-MB for [e-mail]; Fri, 21 May 2004 19:53:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13654 for <[e-mail]>; Fri, 21 May 2004 19:53:50 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJpm-0004bq-MS for [e-mail]; Fri, 21 May 2004 19:53:50 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJon-0004WI-00 for [e-mail]; Fri, 21 May 2004 19:52:50 -0400
Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BRJoB-0004LO-00 for [e-mail]; Fri, 21 May 2004 19:52:11 -0400
Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4LNpVD2004110 for <[e-mail]>; Fri, 21 May 2004 19:51:37 -0400
Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 40A791690016D28B; Fri, 21 May 2004 19:51:32 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
Thread-Index: AcQ8R38ZeEUIpGJFScKig2hEwgaeBADQ6sGA
From: "Fang, Luyuan, ALABS" <[e-mail]>
To: <[e-mail]>, "Susan Hares" <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 21 May 2004 18:51:36 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id UAA00554

Eric,

I focused on the fundamental issue of removing manual work in the last mail, may not be quite clear on the warning limit and reset limit. But I did mention that the "three level threshold" approach makes the prefix limit control to be proactive. 

It is important to have the "three level threshold", here is my thought on this:

The max prefix for PE to stop sending is the 1st priority, it seems you and a few others agreed on this.

The warning limit is also important to be communicated and set at the CE from an operational perspective.  The negotiation of the warning parameter from both sides, allows the a warning to be issued at the provider and the customer.  As the provider and the customer agreed to increase the limit, the new limits can be negotiated while keeping the connection up. The warning limit will allow CE side operators to notice and fix the problems before the Stop limit is reached and the damage is done, this makes customer network management rather proactive than reactive. This is more important for the customer network than the provider network.

The reset/drop limit is needed, because that will provide the last safe guard if the CE did not STOP sending as the result of malfunctioning, etc.  (One of the common types of malfunctioning is the sending of a full routing table or a major portion thereof to a neighbor by mistake.) This last threshold allows some "graceful space" between the STOP limit and the reset limit, and yet protects the PE and the provider network from overrunning the resource.  

For PE, this is very important, to not relying on CE always behaving correctly. To CE, it is rather informational, CE cannot change this threshold on PE. 

Do we need to signal this to CE or not? That's the point of our discussion. The signaling may allow the NOC to alter the reset limit signaled to the CE separate from the ignore limit.

This change can allow different types of errors to have different penalties based on the operational pattern of the CE. That gives the most flexibility for the operation staff to handle errors.

A one size fits all hammer doesn't give us the control as the 3 limits.

Thanks,
Luyuan



-----Original Message-----
From: Eric Rosen [mailto:[e-mail]]
Sent: Monday, May 17, 2004 3:45 PM
To: Susan Hares
Cc: Fang, Luyuan, ALABS; Ash, Gerald R (Jerry), ALABS; Yakov Rekhter;
[e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document 



> Could you be specific on what other thresholds? 

In draft-chavali terminology, I think  Luyuan's argument supports the use of
the "maximum prefix limit" but not  the "reset prefix limit" or the "warning
prefix limit". 

Since the  "maximum prefix limit" is  essentially the same (I  think) as the
"prefix limit" of draft-keyur, I don't think that Luyuan's argument provides
a basis for preferring draft-chavali. 


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA20977 for <[e-mail]>; Fri, 21 May 2004 18:13:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRI8U-0003g3-ER; Fri, 21 May 2004 18:05:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRI5Q-0002Wn-0L for [e-mail]; Fri, 21 May 2004 18:01:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06846 for <[e-mail]>; Fri, 21 May 2004 18:01:47 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRI5N-00026K-7K for [e-mail]; Fri, 21 May 2004 18:01:49 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRI4a-000226-00 for [e-mail]; Fri, 21 May 2004 18:01:01 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BRI3z-0001w2-00 for [e-mail]; Fri, 21 May 2004 18:00:23 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C865D2D4823 for <[e-mail]>; Fri, 21 May 2004 17:59:53 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16255-01-43 for <[e-mail]>; Fri, 21 May 2004 17:59:40 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 25FE22D488F for <[e-mail]>; Fri, 21 May 2004 17:59:27 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] Inter-operable BGP implementations - Call for information 
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Inter-operable BGP implementations - Call for information 
Thread-Index: AcQ+ipLTiWgcThMaQFyPlnSVLHuNFQAOLrBw
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>, "Pekka Savola" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 21 May 2004 17:59:26 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id SAA20977

Curtis and Pekka:

I sent off a bit longer explanation
earlier.  Please let me know if it
was enough.

Having been too verboose this
last week, I was too terse
in the request.

Sue

oh-- well.


-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]]
Sent: Thursday, May 20, 2004 12:49 PM
To: Pekka Savola
Cc: Susan Hares; [e-mail]
Subject: Re: [Idr] Inter-operable BGP implementations - Call for
information 



In message <[e-mail]>, Pekka Savola 
writes:
> On Thu, 20 May 2004, Susan Hares wrote:
> > I am revising the BGP implementation survey, and
> > need an updated on inter-operable implementations.
> > I will accept input for 2 weeks ending 6/2/04.  
> > At that time, I will release version -01 of the BGP
> > implementation survey. 
> 
> FWIW, if you look at RFC2026, it's not sufficient that you have
> interoperable implementations (in general), there must be two
> interoperable implementations of _every feature_ of the spec.
> 
> >From 4.1.2,
>                                                             For the
>    purposes of this section, "interoperable" means to be functionally
>    equivalent or interchangeable components of the system or process in
>    which they are used.
> 
> The interpretation of what this means has been quite blur, but it 
> would be better that if interop tests explicitly tested each feature 
> of the spec, not the spec as a whole.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



Field experience has already proven many BGP implementations to be
interoperable by the definition above.  You can pull out a brand X
router and put in a brand Y router it all works fine, for a large set
of X and Y.

The spec has a lot of MUST and SHOULD and the first survey asked for
an answer for each one of them.  A lot of providers just didn't make
it through verifying which of the SHOULDs they needed to check off
before the cutoff for accepting these (which was just a few weeks).

I don't really know Sue's motivation for this latest request.

What might me useful would be to include the responses to the original
survey, add any that come in, and include the interoperability
experience (without full surveys) that Sue has asked for just as
further evidence that there are a lot of interoperable BGP
implementations.

We should be able to update the protocol experiences doc (if we want
to) after the whole set goes through six months or a year from now if
additional vendors come forward with completed surveys.

Curtis


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA20849 for <[e-mail]>; Fri, 21 May 2004 18:11:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRI8T-0003ft-RF; Fri, 21 May 2004 18:05:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRI5O-0002Wj-N8 for [e-mail]; Fri, 21 May 2004 18:01:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06839 for <[e-mail]>; Fri, 21 May 2004 18:01:46 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRI5L-00026A-QN for [e-mail]; Fri, 21 May 2004 18:01:47 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRI4X-00021p-00 for [e-mail]; Fri, 21 May 2004 18:00:59 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BRI3m-0001uK-00 for [e-mail]; Fri, 21 May 2004 18:00:10 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3BE392D4955 for <[e-mail]>; Fri, 21 May 2004 17:59:41 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15621-01-68 for <[e-mail]>; Fri, 21 May 2004 17:59:28 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 33A9D2D4873 for <[e-mail]>; Fri, 21 May 2004 17:59:26 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] BGP Protocol Experience Draft (-04)
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] BGP Protocol Experience Draft (-04)
Thread-Index: AcQ893qztl3ympD3Q/OmL8bIAnmfuABekJLg
From: "Susan Hares" <[e-mail]>
To: "idr" <[e-mail]>
Cc: "Keyur Patel" <[e-mail]>, "Danny McPherson" <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 21 May 2004 17:59:25 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id SAA20849

idr working group:

We will start a 1 week Last Call on the
BGP protocol Experience Draft revision
that Danny explains below.  

Please send any comments on the

 draft-ietf-idr-bgp4-experience-protocol-04.txt

This Last call will end 5/27/04. 

Sue 

 

-----Original Message-----
From: Danny McPherson [mailto:[e-mail]]
Sent: Tuesday, May 18, 2004 12:18 PM
To: idr
Cc: Keyur Patel
Subject: [Idr] BGP Protocol Experience Draft (-04)



I just posted an update version of the BGP Protocol Experience
draft.  Not much changed, here's a diff from the -03 revision,
the new version (-04) should be available in the Internet-Drafts
repository RSN.

Not sure if it needs to relive WG LC or not..

-danny



< Expires: March 2004                           September 2003
---
 > Expires: November 2004                              May 2004
10c10
<             <draft-ietf-idr-bgp4-experience-protocol-03.txt>
---
 >             <draft-ietf-idr-bgp4-experience-protocol-04.txt>
45c45
<    Copyright (C) The Internet Society (2003). All Rights Reserved.
---
 >    Copyright (C) The Internet Society (2004). All Rights Reserved.
54c54
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
110c110
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
120c120
<    4. Implementations. . . . . . . . . . . . . . . . . . . . . . . .  
  5
---
 >    4. Implementation Information . . . . . . . . . . . . . . . . . .  
  5
129c129
<    8. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . .  
  9
---
 >    8. Local Preference . . . . . . . . . . . . . . . . . . . . . . .  
  9
135c135
<     13.1. Consideration of TCP Characteristics . . . . . . . . . . .  
13
---
 >     13.1. Consideration of TCP Characteristics . . . . . . . . . . .  
14
140c140
<     17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . .  
15
---
 >     17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . .  
16
142c142
<     17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . .  
16
---
 >     17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . .  
17
146c146
<     A Bit of History . . . . . . . . . . . . . . . . . . . . . . . .  
17
---
 >     A Bit of History . . . . . . . . . . . . . . . . . . . . . . . .  
18
166c166
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
222c222
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
243c243
< 4.  Implementations
---
 > 4.  Implementation Information
278c278
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
287c287
<    Confederations for BGP, and perhaps some mix of the two.  BGP Route
---
 >    Confederations for BGP, and often some mix of the two.  BGP Route
305c305
<    120,000 aggregate entries, representing several times that number 
of
---
 >    134,000 aggregate entries, representing several times that number 
of
307c307
<    provider core routers exceeds 2.5 million.  Native AS_PATH lengths
---
 >    provider core routers exceeds 2.5 million.  Native AS path lengths
309c309
<    more ASs exist.
---
 >    more autonomous systems exist.
334c334
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
341,342c341,342
<    is used as a metric by EBGP peers while BGP Local Preference is 
used
<    by IBGP peers.
---
 >    is used as a metric by EBGP peers (i.e., inter-domain) while Local
 >    Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain).
358c358
<    different ASs as well.
---
 >    different autonomous systems as well.
366,371c366,371
<    between multiple paths learned from a single AS, it can result in
<    potentially bad decisions when comparing MEDs between different
<    automomous systems.  This is most typically the case when the
<    autonomous systems use different mechanisms to derive IGP metrics,
<    BGP MEDs, or perhaps even use different IGP procotols with vastly
<    contrasting metric spaces.
---
 >    between multiple paths learned from a single adjacent AS, it can
 >    result in potentially bad decisions when comparing MEDs between
 >    different automomous systems.  This is most typically the case when
 >    the autonomous systems use different mechanisms to derive IGP
 >    metrics, BGP MEDs, or perhaps even use different IGP procotols with
 >    vastly contrasting metric spaces.
390c390
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
430a431,434
 >    Seemingly more intuitive references that fall outside the vegetable
 >    kingdom refer to cold potatoe routing as "best exit routing", and 
hot
 >    potatoe routing as "closest exit routing", though vegetable.
 >
437,440d440
<    be passed to its IBGP peers.  Although advertising MEDs to IBGP 
peers
<    is not a required behavior, it is a common default.  MEDs received
<    from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP
<    peers.
446c446
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
448a449,453
 >    be passed to its IBGP peers.  Although advertising MEDs to IBGP 
peers
 >    is not a required behavior, it is a common default.  MEDs received
 >    from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP
 >    peers.
 >
459,462c464,467
<    An implementation MUST provide a mechanism that allows for MED to 
be
<    removed.  Previously, implementations did not consider a missing 
MED
<    value to be the same as a MED of zero.  No MED value should now be
<    equal to a value of zero.
---
 >    [BGP4] requires that an implementation must provide a mechanism 
that
 >    allows for MED to be removed.  Previously, implementations did not
 >    consider a missing MED value to be the same as a MED of zero.  
[BGP4]
 >    now requires that no MED value be equal to a value of zero.
464c469
<    Note that many implementations provide an mechanism to explicitly
---
 >    Note that many implementations provide a mechanism to explicitly
479c484
<    non-deterministic behavior, and as such, is often undesirable.
---
 >    non-deterministic behavior, and as such, may often be undesirable.
483c488
< 8.  LOCAL_PREF
---
 > 8.  Local Preference
492,496d496
<    default value of LOCAL-PREF to be assumed if none was provided.
<    Defaults of 0 or the maximum value each have range limitations, so 
a
<    common default would aid in the interoperation of multi-vendor
<    routers in the same AS (since LOCAL_PREF is a local administration
<    knob, there is no interoperability drawback across AS boundaries).
502c502
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
505,507c505,514
<    The LOCAL_PREF MUST be sent to IBGP Peers.  The LOCAL_PREF 
Attribute
<    MUST NOT be sent to EBGP Peers.  Although no default value for
<    LOCAL_PREF is defined, the common default value is 100.
---
 >    default value of LOCAL_PREF to be assumed if none was provided.
 >    Defaults of 0 or the maximum value each have range limitations, so 
a
 >    common default would aid in the interoperation of multi-vendor
 >    routers in the same AS (since LOCAL_PREF is a local administration
 >    attribute, there is no interoperability drawback across AS
 >    boundaries).
 >
 >    [BGP4] requires that LOCAL_PREF be sent to IBGP Peers and must not 
be
 >    sent to EBGP Peers.  Although no default value for LOCAL_PREF is
 >    defined, the common default value is 100.
526c533
<    possibility of carrying an optional vector corresponding to the AS-
---
 >    possibility of carrying an optional vector corresponding to the AS_
528,534c535,542
<    given route.  Cooperating ASs may then chose traffic based upon
<    comparison of "interesting" portions of this vector according to
<    routing policy.
<
<    While protecting a given ASs routing policy is of paramount 
concern,
<    avoiding extensive hand configuration of routing policies needs to 
be
<    examined more carefully in future BGP-like protocols.
---
 >    given route.  Cooperating autonomous systems may then chose traffic
 >    based upon comparison of "interesting" portions of this vector
 >    according to routing policy.
 >
 >    While protecting a given autonoumous systems routing policy is of
 >    paramount concern, avoiding extensive hand configuration of routing
 >    policies needs to be examined more carefully in future BGP-like
 >    protocols.
545,552d552
<    information to all other transit and border routers within that AS.
<    This is typically done by establishing internal BGP connections to
<    all transit and border routers in the local AS.
<
<    Note that the number of BGP peers that can be fully meshed depends 
on
<    a number of factors, to include number of prefixes in the routing
<    system, stability of the system, and perhaps most importantly,
<    implementation ifficiency.  As a result, although it's difficult to
558c558
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
561,562c561,570
<    define "a large number of peers", there is always some practical
<    limit.
---
 >    information to all other transit and border routers within that AS.
 >    This is typically done by establishing internal BGP connections to
 >    all transit and border routers in the local AS.
 >
 >    Note that the number of BGP peers that can be fully meshed depends 
on
 >    a number of factors, to include number of prefixes in the routing
 >    system, number of unique path, stability of the system, and perhaps
 >    most importantly, implementation efficiency.  As a result, although
 >    it's difficult to define "a large number of peers", there is always
 >    some practical limit.
582,583c590,591
<    Internet.  As the net has grown, the number of route changes per
<    second has increased.
---
 >    Internet.  As the Internet has grown, the frequency of route 
changes
 >    per second has increased.
600c608,616
<    manditory in RFC 2439.  A potential result of failure to consider
---
 >    mandatory in RFC 2439.  A potential result of failure to consider
 >
 >
 >
 > McPherson, Patel                                  Section 10.  [Page 
11]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
609,620c625,628
<
<
<
< McPherson, Patel                                  Section 10.  [Page 
11]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
<    changes to be announced are inefficiently packed.  As previously
<    discussed, announcing routing changes sharing common attributes in 
a
<    single BGP UPDATE message helps save considerable bandwidth and 
lower
<    processing overhead.
---
 >    changes to be announced are inefficiently packed.  As discussed in 
a
 >    later section, announcing routing changes sharing common attributes
 >    in a single BGP UPDATE message helps save considerable bandwidth 
and
 >    lower processing overhead.
656a665,672
 >
 >
 >
 > McPherson, Patel                                  Section 12.  [Page 
12]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
665,672d680
<
<
<
< McPherson, Patel                                  Section 12.  [Page 
12]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
712a721,728
 >
 >
 >
 > McPherson, Patel                                  Section 13.  [Page 
13]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
721,728d736
<
<
<
< McPherson, Patel                                Section 13.1.  [Page 
13]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
738,741c746,749
<    buffer can grow until memory is exhausted.  A BGP implementation 
must
<    send changes to all peers for which the TCP connection is not 
blocked
<    and must remember to send those changes to the remaining peers when
<    the connection becomes unblocked.
---
 >    buffer can grow until memory is exhausted.  A BGP implementation is
 >    required to send changes to all peers for which the TCP connection 
is
 >    not blocked and is required to remember to send those changes to 
the
 >    remaining peers when the connection becomes unblocked.
769,773d776
<    Implementers may find it useful to order path attributes according 
to
<    Type Code so that sets of attributes with identical semantics can 
be
<    more quickly identified.
<
<
776a780,782
 > McPherson, Patel                                  Section 14.  [Page 
14]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
778a785,787
 >    Implementers may find it useful to order path attributes according 
to
 >    Type Code so that sets of attributes with identical semantics can 
be
 >    more quickly identified.
780,782d788
< McPherson, Patel                                  Section 14.  [Page 
14]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
802c808,810
<    to BGP-4 should provide the version support on a per-peer basis.
---
 >    to BGP-4 should provide the version support on a per-peer basis.  
At
 >    the time of this writing all BGP speakers on the Internet are 
thought
 >    to be running BGP version 4.
822a831,840
 >
 >
 >
 >
 >
 > McPherson, Patel                                  Section 17.  [Page 
15]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
833,840d850
<
<
<
< McPherson, Patel                                Section 17.1.  [Page 
15]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
844a855,867
 >    It was naively assumed by many for some time that in order to 
inject
 >    a data segement or reset a TCP transport connection between two BGP
 >    peers an attacker must correctly guess the exact TCP sequence 
number
 >    (of course, in addition to source and destination ports and IP
 >    addresses).  However, it has recently been observed and openly
 >    discussed that the malicous data only needs to fall within the TCP
 >    receive window, which may be quite large, thereby significantly
 >    lowering the complexity of such an attack.
 >
 >    As such, it is recommended that the MD5 TCP Signature Option be
 >    employed to protect BGP from session resets and malicious data
 >    injection.
 >
867a891,896
 >
 > McPherson, Patel                                Section 17.2.  [Page 
16]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
888,896d916
<
<
<
<
< McPherson, Patel                                Section 17.3.  [Page 
16]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
924a945,952
 >
 >
 >
 > McPherson, Patel                                Section 17.5.  [Page 
17]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
946,952d973
<
<
< McPherson, Patel                                Section 17.6.  [Page 
17]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
979a1001,1008
 >
 >
 >
 > McPherson, Patel                                Section 17.6.  [Page 
18]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
1004,1008d1032
< McPherson, Patel                                Section 17.6.  [Page 
18]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
1036,1059d1059
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
1062c1062
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
1118c1118
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
1139c1139,1140
<    [BGP4-ANALYSIS] Work in Progress.
---
 >    [BGP4-ANALYSIS] "BGP-4 Protocol Analysis", Internet-Draft, Work in
 >               Progress.
1141c1142,1143
<    [BGP4-IMPL] Work in Progress.
---
 >    [BGP4-IMPL] "BGP 4 Implementation Report ", Internet-Draft, Work
 >               in Progress.
1146c1148
<    [SBGP]
---
 >    [SBGP]  "Secure BGP", Internet-Draft, Work in Progress.
1148c1150
<    [soBGP]
---
 >    [soBGP] "Secure Origin BGP", Internet-Draft, Work in Progress.
1170,1171d1171
<
<
1174c1174
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
1179c1179
<    Copyright (C) The Internet Society (2003). All Rights Reserved.
---
 >    Copyright (C) The Internet Society (2004). All Rights Reserved.


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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA20692 for <[e-mail]>; Fri, 21 May 2004 18:09:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRI8T-0003fj-7s; Fri, 21 May 2004 18:05:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRI5N-0002Wh-8r for [e-mail]; Fri, 21 May 2004 18:01:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06836 for <[e-mail]>; Fri, 21 May 2004 18:01:44 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRI5K-00025w-Hj for [e-mail]; Fri, 21 May 2004 18:01:46 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRI4W-00021f-00 for [e-mail]; Fri, 21 May 2004 18:00:56 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BRI3k-0001rP-00 for [e-mail]; Fri, 21 May 2004 18:00:08 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 1AEF02D48E2 for <[e-mail]>; Fri, 21 May 2004 17:59:39 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16256-03-32 for <[e-mail]>; Fri, 21 May 2004 17:59:25 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6E45E2D486F for <[e-mail]>; Fri, 21 May 2004 17:59:25 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] Inter-operable BGP implementations - Call for information
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Inter-operable BGP implementations - Call for information
Thread-Index: AcQ+Lqj4xxlhquS3SoyoY3DrcYTNwgAN8icw
From: "Susan Hares" <[e-mail]>
To: "Pekka Savola" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 21 May 2004 17:59:25 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id SAA20692

Pekka:

In my earlier messages I assumed a context
from bgp-4 implementation report found
for your reading pleasure (and accessed
off the general IDR web page) at:

 draft-ietf-idr-bgp-implementation-00.txt 

In that report (authored by Alvaro and
myself), we have 4 inter-operable (Alcatel,
Cisco, Laurel, NextHop) whose inventors
responded to 259 questions required to verify
all features of the protocols.
This required a significant investment
of time on for any implementer.  
All issues from RFC 2026 are covered
in that document. 

Since there are greater than four implementations
of BGP in existence, the small subset of
responses will be of concern to any
member of the IESG with functioning
and engaged cognitive processes.  

Informal reports to me indicated that
for an existing and deployed implementation, this
effort had value only for the continuation of
the IETF standard process.   In order to
provide appropriate input to the IESG on
general interoperability of BGP, I need to
widen the normal 2026 survey to
include those implementations that: 	

 a)Are inter-operable with other BGP implementation, and
 b)whose implementers found that answering 259
   questions on an existing and deployed 
   implementations was too daunting to
   complete.

Section 1.4 of the implementation report
deals with this issue.  At the time of the -00.txt
draft this was incomplete because I 
did not have enough time to get a significant
number of responses.  I am now asking for
those responses in the next 2 weeks. 

Does this make the request clear? 

Perhaps this two facts will also illuminate the
value of this request to the working group.
For example, neither Juniper or Redback's
implementers filled out an implementation report.
Juniper's support of BGP standardization process has
been evident by my esteemed co-chairs active
participation for years.  Other standards or
standards reports have been generated by 
many fine BGP implementers at Juniper or Redback.

I normally attempt to be brief and assume
a substantial amount of context from existing
documents.  Please send me feedback if I am
being to terse in the future.  

Sue 


	

-----Original Message-----
From: Pekka Savola [mailto:[e-mail]]
Sent: Thursday, May 20, 2004 1:52 AM
To: Susan Hares
Cc: [e-mail]
Subject: Re: [Idr] Inter-operable BGP implementations - Call for
information


On Thu, 20 May 2004, Susan Hares wrote:
> I am revising the BGP implementation survey, and
> need an updated on inter-operable implementations.
> I will accept input for 2 weeks ending 6/2/04.  
> At that time, I will release version -01 of the BGP
> implementation survey. 

FWIW, if you look at RFC2026, it's not sufficient that you have
interoperable implementations (in general), there must be two
interoperable implementations of _every feature_ of the spec.

>From 4.1.2,
                                                            For the
   purposes of this section, "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used.

The interpretation of what this means has been quite blur, but it 
would be better that if interop tests explicitly tested each feature 
of the spec, not the spec as a whole.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA10091 for <[e-mail]>; Fri, 21 May 2004 15:59:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRG7k-00073h-FL; Fri, 21 May 2004 15:56:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFzn-0005fj-DC for [e-mail]; Fri, 21 May 2004 15:47:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25219 for <[e-mail]>; Fri, 21 May 2004 15:47:52 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRFzl-00016D-SK for [e-mail]; Fri, 21 May 2004 15:47:53 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRFxS-0000ef-00 for [e-mail]; Fri, 21 May 2004 15:45:32 -0400
Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRFuk-000087-00 for [e-mail]; Fri, 21 May 2004 15:42:42 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BRFXh-0003rn-6x for [e-mail]; Fri, 21 May 2004 15:18:53 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 May 2004 11:24:35 +0000
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4LJIJ8R015632; Fri, 21 May 2004 12:18:20 -0700 (PDT)
Received: from [192.168.42.3] (dhcp-64-101-214-222.cisco.com [64.101.214.222]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA29003; Fri, 21 May 2004 15:18:19 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p060204cdbcd40696f713@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Pekka Savola <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 21 May 2004 15:19:01 -0400

Seems a good idea to me.

--John

At 7:21 AM +0300 5/21/04, Pekka Savola wrote:
>FYI --
>
>As there seemed to be consensus for moving RFC 1863 to historic, I
>made a short I-D to document it.
>
>Comments, adoption as WG doc, ...?
...

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA06060 for <[e-mail]>; Fri, 21 May 2004 15:09:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFLK-0005nP-6X; Fri, 21 May 2004 15:06:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRF7U-0002oO-DA for [e-mail]; Fri, 21 May 2004 14:51:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21311 for <[e-mail]>; Fri, 21 May 2004 14:51:44 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRF7R-0004XS-8m for [e-mail]; Fri, 21 May 2004 14:51:45 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRF6a-0004Sz-00 for [e-mail]; Fri, 21 May 2004 14:50:53 -0400
Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BRF6D-0004O8-00 for [e-mail]; Fri, 21 May 2004 14:50:29 -0400
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 18A8E75C5C9; Fri, 21 May 2004 11:50:28 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29864-02; Fri, 21 May 2004 11:50:27 -0700 (PDT)
Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id A8B3775C5C6; Fri, 21 May 2004 11:50:27 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id D430515D3C1; Fri, 21 May 2004 11:50:26 -0700 (PDT)
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] draft-chen-bgp-prefix-orf-07.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 21 May 2004 11:50:26 -0700

Hi, Yakov and Sue:

We already have the prefix ORF as part of the milestones in the IDR charter:

   May 04  Submit Outbound Route Filter, Prefix and ASpath ORF draft to
           IESG as a Proposed Standard

So, may I suggest <draft-chen-bgp-prefix-orf-07.txt> be adopted as an IDR
WG document?  The prefix ORF described in the draft has been implemented
by several vendors, and deployed for several years.

Thanks.  -- Enke

------- Forwarded Message

Message-Id: <[e-mail]>
To: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-chen-bgp-prefix-orf-07.txt
Date: Mon, 10 May 2004 16:20:40 -0400

---NextPart

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

	Title		: Address Prefix Based Outbound Route Filter for BGP-4
	Author(s)	: E. Chen, S. Sangli
	Filename	: draft-chen-bgp-prefix-orf-07.txt
	Pages		: 5
	Date		: 2004-5-10
	
This document defines a new Outbound Router Filter type for BGP,
termed 'Address Prefix Outbound Route Filter', that can be used to
perform address prefix based route filtering. This ORF-type supports
prefix length or range based matching, wild-card based address prefix
matching, as well as the exact address prefix matching for address
families.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-07.txt

------- End of Forwarded Message


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA12600 for <[e-mail]>; Fri, 21 May 2004 00:33:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1cb-0004ox-Aj; Fri, 21 May 2004 00:27:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1Zq-00047i-S7 for [e-mail]; Fri, 21 May 2004 00:24:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19246 for <[e-mail]>; Fri, 21 May 2004 00:24:07 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR1Zo-0005D9-B3 for [e-mail]; Fri, 21 May 2004 00:24:08 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR1Yp-00055Z-00 for [e-mail]; Fri, 21 May 2004 00:23:08 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BR1Xr-0004uw-00 for [e-mail]; Fri, 21 May 2004 00:22:07 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4L4Lcl20865 for <[e-mail]>; Fri, 21 May 2004 07:21:38 +0300
From: Pekka Savola <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd)
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 21 May 2004 07:21:37 +0300 (EEST)

FYI --

As there seemed to be consensus for moving RFC 1863 to historic, I 
made a short I-D to document it.

Comments, adoption as WG doc, ...?

---------- Forwarded message ----------
Date: Thu, 20 May 2004 16:01:08 -0400
From: [e-mail]
To: [e-mail]
Subject: I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt

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


	Title		: Request to Move RFC 1863 to Historic
	Author(s)	: P. Savola
	Filename	: draft-savola-idr-rfc1863-historic-00.txt
	Pages		: 4
	Date		: 2004-5-20
	
This memo requests moving RFC 1863, A BGP/IDRP Route Server"M
alternative to a full mesh routing, to Historic status.  This memo"M
also Obsoletes RFC 1863.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-savola-idr-rfc1863-historic-00.txt


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03800 for <[e-mail]>; Thu, 20 May 2004 13:15:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqro-0002Iq-Rr; Thu, 20 May 2004 12:58:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqn0-0006ip-5g for [e-mail]; Thu, 20 May 2004 12:53:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01406 for <[e-mail]>; Thu, 20 May 2004 12:52:58 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqmy-0005bJ-Dm for [e-mail]; Thu, 20 May 2004 12:53:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqlq-0005Qi-00 for [e-mail]; Thu, 20 May 2004 12:51:51 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BQqkK-0005BT-00 for [e-mail]; Thu, 20 May 2004 12:50:16 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4KGnA0N014365; Thu, 20 May 2004 12:49:11 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pekka Savola <[e-mail]>
cc: Susan Hares <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] Inter-operable BGP implementations - Call for information 
In-reply-to: Your message of "Thu, 20 May 2004 08:52:17 +0300." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 20 May 2004 12:49:10 -0400

In message <[e-mail]>, Pekka Savola 
writes:
> On Thu, 20 May 2004, Susan Hares wrote:
> > I am revising the BGP implementation survey, and
> > need an updated on inter-operable implementations.
> > I will accept input for 2 weeks ending 6/2/04.  
> > At that time, I will release version -01 of the BGP
> > implementation survey. 
> 
> FWIW, if you look at RFC2026, it's not sufficient that you have
> interoperable implementations (in general), there must be two
> interoperable implementations of _every feature_ of the spec.
> 
> >From 4.1.2,
>                                                             For the
>    purposes of this section, "interoperable" means to be functionally
>    equivalent or interchangeable components of the system or process in
>    which they are used.
> 
> The interpretation of what this means has been quite blur, but it 
> would be better that if interop tests explicitly tested each feature 
> of the spec, not the spec as a whole.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



Field experience has already proven many BGP implementations to be
interoperable by the definition above.  You can pull out a brand X
router and put in a brand Y router it all works fine, for a large set
of X and Y.

The spec has a lot of MUST and SHOULD and the first survey asked for
an answer for each one of them.  A lot of providers just didn't make
it through verifying which of the SHOULDs they needed to check off
before the cutoff for accepting these (which was just a few weeks).

I don't really know Sue's motivation for this latest request.

What might me useful would be to include the responses to the original
survey, add any that come in, and include the interoperability
experience (without full surveys) that Sue has asked for just as
further evidence that there are a lot of interoperable BGP
implementations.

We should be able to update the protocol experiences doc (if we want
to) after the whole set goes through six months or a year from now if
additional vendors come forward with completed surveys.

Curtis


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA26320 for <[e-mail]>; Thu, 20 May 2004 12:02:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpl7-0001Er-P9; Thu, 20 May 2004 11:47:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp8P-0004mG-5Z for [e-mail]; Thu, 20 May 2004 11:07:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22199 for <[e-mail]>; Thu, 20 May 2004 11:06:56 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQp8M-00078L-Cy for [e-mail]; Thu, 20 May 2004 11:06:58 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQp7O-0006up-00 for [e-mail]; Thu, 20 May 2004 11:05:58 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BQp6u-0006h4-00 for [e-mail]; Thu, 20 May 2004 11:05:28 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4KF3Z0N014204; Thu, 20 May 2004 11:03:35 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Stephen Kent <[e-mail]>
cc: "John G. Scudder" <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] proposed additional text 
In-reply-to: Your message of "Mon, 17 May 2004 15:11:55 EDT." <p06100509bccead228003@[128.89.89.75]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 20 May 2004 11:03:35 -0400

In message <p06100509bccead228003@[128.89.89.75]>, Stephen Kent writes:
> John,
> 
> >>    RFC 2385 does not specify a means of managing (e.g., generating
> >>    and distributing) the keys used to compute the MAC. A different
> >>    key should be used for each protected peer. If the same key is used
> >>    for multiple peers, the offered security services are degraded.
> >
> >I assume this refers to the increased probability of the key being 
> >operationally compromised. Perhaps this should be made explicit.
> 
> There are several concerns. Use of a key in other than a pairwise 
> disjoint fashion  undermines the data origin authentication service, 
> because other than the peer router can generate traffic that will be 
> treated as being from the peer. Also, if the router interface 
> addresses used on a link are not globally unique, then traffic from 
> one link could be injected into another link and accepted as valid, 
> if the same key is used. And, as you noted, more widespread 
> distribution of a secret key generally increases the likelihood that 
> the key may be compromised.


Common practice is to put the same key in all core routers of a given
provider.  The thinking there is if a core router is compromised the
provider has more important things to worry about than BGP replay
attacks.  Yes it would be better to have separate keys.  This just
happens to be a common choice.

The providers I worked for never used the same encryption keys for
anything for routers that were on customer premise.


> >>    (In fact, the reuse of the same key with the same peer for multiple
> >>    TCP connections already represents a vulnerability, as noted above.)
> >
> >The parenthetical comment has an unresolved reference -- the "noted 
> >above" ain't above. (Unless this relates to something already in the 
> >spec and not the proposed text?)
> 
> Strike the "as the noted above" text.  The vulnerability here is that 
> traffic from one TCP connection between two routers can be replayed 
> into a later connection, when sequence numbers align appropriately, 
> because the same key is used for many TCP connections (over time) 
> between a pair of routers.


Each BGP session will have a unique key pair.  The router that is on
the TCP accept end of the connection has port 179 but the other port
number is randomly chosen with each session.  Therefore you can't
replay from one session into the next.  If a BGP cease occurs due to
misaligned packets in a insertion attempt, all previously snooped
packets become of no value to the attacker.


> Steve

Curtis

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA29594 for <[e-mail]>; Thu, 20 May 2004 02:02:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQgY9-0000Dq-Tx; Thu, 20 May 2004 01:57:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQgVc-00080I-Jt for [e-mail]; Thu, 20 May 2004 01:54:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15792 for <[e-mail]>; Thu, 20 May 2004 01:54:22 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQgVZ-00039z-Al for [e-mail]; Thu, 20 May 2004 01:54:21 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQgUf-00031p-00 for [e-mail]; Thu, 20 May 2004 01:53:26 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BQgUD-0002sY-00 for [e-mail]; Thu, 20 May 2004 01:52:57 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4K5qHg32096; Thu, 20 May 2004 08:52:17 +0300
From: Pekka Savola <[e-mail]>
To: Susan Hares <[e-mail]>
cc: [e-mail]
Subject: Re: [Idr] Inter-operable BGP implementations - Call for information
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 20 May 2004 08:52:17 +0300 (EEST)

On Thu, 20 May 2004, Susan Hares wrote:
> I am revising the BGP implementation survey, and
> need an updated on inter-operable implementations.
> I will accept input for 2 weeks ending 6/2/04.  
> At that time, I will release version -01 of the BGP
> implementation survey. 

FWIW, if you look at RFC2026, it's not sufficient that you have
interoperable implementations (in general), there must be two
interoperable implementations of _every feature_ of the spec.

>From 4.1.2,
                                                            For the
   purposes of this section, "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used.

The interpretation of what this means has been quite blur, but it 
would be better that if interop tests explicitly tested each feature 
of the spec, not the spec as a whole.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA27091 for <[e-mail]>; Thu, 20 May 2004 01:29:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQg2D-0001b8-9f; Thu, 20 May 2004 01:24:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQfyg-0000Xl-Rm for [e-mail]; Thu, 20 May 2004 01:20:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14412 for <[e-mail]>; Thu, 20 May 2004 01:20:20 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQfyd-0005d5-UY for [e-mail]; Thu, 20 May 2004 01:20:19 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQfxe-0005UN-00 for [e-mail]; Thu, 20 May 2004 01:19:19 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BQfwo-0005Dg-00 for [e-mail]; Thu, 20 May 2004 01:18:26 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EEDE72D487C for <[e-mail]>; Thu, 20 May 2004 01:17:57 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 54387-01-10 for <[e-mail]>; Thu, 20 May 2004 01:17:45 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BD3892D4838 for <[e-mail]>; Thu, 20 May 2004 01:17:45 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] proposed additional text
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] proposed additional text
Thread-Index: AcQ8FhxwbmUFywihTt+GMWlzyWLGXgCE270A
From: "Susan Hares" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 20 May 2004 01:17:45 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id BAA27091

Yakov:

this sentence is confusing.

   Absent use of mechanisms that effect
   these security services, attackers can disrupt these TCP connections
   and/or masquerade as a legitimate peer router.

Is it 
   Absent the use of mechanisms that effect these
   security services, attackers can disrupt these TCP connections
   and/or masquerade as a legitimate peer router.

If not, could you are Steve explain what it really means.

Sue

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]]
Sent: Monday, May 17, 2004 9:45 AM
To: [e-mail]
Subject: [Idr] proposed additional text


Folks,

During the IESG review Steve Kent proposed the following text to
be added to the BGP protocol spec. 

   BGP makes use of TCP for reliable transport of its traffic between
   peer routers. To provide connection-oriented integrity and data
   origin authentication, on a point-to-point basis, BGP specifies
   use of the mechanism defined in RFC 2385. These services are intended
   to detect and reject active wiretapping attacks against the
   inter-router TCP connections. Absent use of mechanisms that effect
   these security services, attackers can disrupt these TCP connections
   and/or masquerade as a legitimate peer router. Because the mechanism
   defined in the RFC does not provide peer-entity authentication,
   these connections are still subject to some forms of replay attacks.
   
   The mechanism defined in RFC 2385 augments the normal TCP checksum
   with a 16-byte message authentication code (MAC) that is computed
   over the same data as the TCP checksum. This MAC is based on a
   one-way hash function (MD5) and use of a secret key. The key is
   shared between peer routers and is used to generate MAC values that
   are not readily computed by an attacker who does not have access
   to the key. A compliant implementation must support this mechanism,
   and must allow a network administrator to activate it on a per-peer
   basis.
   
   RFC 2385 does not specify a means of managing (e.g., generating
   and distributing) the keys used to compute the MAC. A different
   key should be used for each protected peer. If the same key is used
   for multiple peers, the offered security services are degraded.
   (In fact, the reuse of the same key with the same peer for multiple
   TCP connections already represents a vulnerability, as noted above.)
   Obviously, each  key also should be chosen so as to be hard for an
   attacker to guess.  The techniques specified in RFC 1750 for random
   number generation provide a guide for generation of values that
   could be used as keys. Keys also should be changed periodically,
   to minimize the impact of a key compromise or successful cryptanalytic
   attack.
   
   RFC 2385 calls for implementations to support keys "composed of a
   string of printable ASCII of 80 bytes or less ."  While it is
   difficult to specify an appropriate key size for a wide range of
   environments, it is worth noting that current standards for analogous
   integrity algorithms make use of key sizes of about 128-256 bits.
   An 80-byte, printable ASCII string, falls into this range.

If there are any objections to adding this text to the protocol
spec please post them to the list by May 24, 2004.

Yakov.

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

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA23732 for <[e-mail]>; Thu, 20 May 2004 00:45:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQfIj-0006TE-Da; Thu, 20 May 2004 00:37:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnd6-00072h-P8 for [e-mail]; Mon, 17 May 2004 15:18:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17050 for <[e-mail]>; Mon, 17 May 2004 15:18:27 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPnd5-0004YA-H4 for [e-mail]; Mon, 17 May 2004 15:18:27 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPncL-0004CQ-00 for [e-mail]; Mon, 17 May 2004 15:17:41 -0400
Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BPnbU-0003mF-00 for [e-mail]; Mon, 17 May 2004 15:16:48 -0400
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4HJFw7X028903; Mon, 17 May 2004 15:15:59 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06100509bccead228003@[128.89.89.75]>
In-Reply-To: <p06020492bcce88c75148@[192.168.42.3]>
References: <[e-mail]> <p06020492bcce88c75148@[192.168.42.3]>
To: "John G. Scudder" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: [Idr] proposed additional text
Cc: Yakov Rekhter <[e-mail]>, [e-mail], Stephen  Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 15:11:55 -0400

John,

>>    RFC 2385 does not specify a means of managing (e.g., generating
>>    and distributing) the keys used to compute the MAC. A different
>>    key should be used for each protected peer. If the same key is used
>>    for multiple peers, the offered security services are degraded.
>
>I assume this refers to the increased probability of the key being 
>operationally compromised. Perhaps this should be made explicit.

There are several concerns. Use of a key in other than a pairwise 
disjoint fashion  undermines the data origin authentication service, 
because other than the peer router can generate traffic that will be 
treated as being from the peer. Also, if the router interface 
addresses used on a link are not globally unique, then traffic from 
one link could be injected into another link and accepted as valid, 
if the same key is used. And, as you noted, more widespread 
distribution of a secret key generally increases the likelihood that 
the key may be compromised.

>
>>    (In fact, the reuse of the same key with the same peer for multiple
>>    TCP connections already represents a vulnerability, as noted above.)
>
>The parenthetical comment has an unresolved reference -- the "noted 
>above" ain't above. (Unless this relates to something already in the 
>spec and not the proposed text?)

Strike the "as the noted above" text.  The vulnerability here is that 
traffic from one TCP connection between two routers can be replayed 
into a later connection, when sequence numbers align appropriately, 
because the same key is used for many TCP connections (over time) 
between a pair of routers.

Steve

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA22501 for <[e-mail]>; Thu, 20 May 2004 00:28:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQf6I-0003dd-Rp; Thu, 20 May 2004 00:24:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQf2p-0002jJ-Ra for [e-mail]; Thu, 20 May 2004 00:20:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11671 for <[e-mail]>; Thu, 20 May 2004 00:20:32 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQf2n-0003rY-Cg for [e-mail]; Thu, 20 May 2004 00:20:33 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQf1w-0003gn-00 for [e-mail]; Thu, 20 May 2004 00:19:40 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BQf1B-0003Ul-00 for [e-mail]; Thu, 20 May 2004 00:18:53 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E486F2D4939 for <[e-mail]>; Thu, 20 May 2004 00:18:17 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 52041-02-38 for <[e-mail]>; Thu, 20 May 2004 00:18:06 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 472922D4923 for <[e-mail]>; Thu, 20 May 2004 00:18:06 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: Inter-operable BGP implementations - Call for information 
Thread-Index: AcQ99tU2W9axkZ1HQlSTCqurauSjEw==
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] Inter-operable BGP implementations - Call for information
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 20 May 2004 00:18:05 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id AAA22501

IDR folks: 

I am revising the BGP implementation survey, and
need an updated on inter-operable implementations.
I will accept input for 2 weeks ending 6/2/04.  
At that time, I will release version -01 of the BGP
implementation survey. 

If you have an implementation of BGP and
you did not send in an implementation report
(answering the 259 questions),  could
you send me the answer the following questions

1) BGP product
	Contributor (your name): 
	Company: 
	name of product: 
	version and minor of software
	release date

2) What other implementations you 
     interoperate with.
	
   
3) Do you inter-operate with

	1) Alcatel BGP (release) 
	2) cisco BGP IOS 12.0(27)s
	3) laurel BGP (specify release)
	4) NextHop GateD

4) Did the length of the survey for BGP
   cause you to not submit the BGP
   implementation report?




Sue Hares 


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA04001 for <[e-mail]>; Wed, 19 May 2004 20:28:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbK0-0006pQ-69; Wed, 19 May 2004 20:22:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbDG-0004wR-D0 for [e-mail]; Wed, 19 May 2004 20:15:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00555 for <[e-mail]>; Wed, 19 May 2004 20:15:04 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQbDE-0000c8-8n for [e-mail]; Wed, 19 May 2004 20:15:04 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQbCN-0000VH-00 for [e-mail]; Wed, 19 May 2004 20:14:12 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQbBM-0000It-00 for [e-mail]; Wed, 19 May 2004 20:13:08 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 May 2004 16:20:10 +0000
Received: from cisco.com (shako.cisco.com [64.102.17.78]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4K0Caf9010662 for <[e-mail]>; Wed, 19 May 2004 17:12:37 -0700 (PDT)
Received: from localhost (rtp-vpn2-370.cisco.com [10.82.241.114]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA01675 for <[e-mail]>; Wed, 19 May 2004 20:12:36 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] I-D ACTION:draft-ng-sobgp-bgp-extensions-02.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 19 May 2004 20:12:34 -0400 (Eastern Daylight Time)

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


	Title		: Extensions to BGP to Support Secure Origin BGP
(soBGP)
	Author(s)	: J. Ng
	Filename	: draft-ng-sobgp-bgp-extensions-02.txt
	Pages		: 16
	Date		: 2004-4-16

There is a great deal of concern over the security of routing systems
within the Internet, particularly in relation to the Border Gateway
Protocol [BGP], which is used to provide routing information between
autonomous systems. This document proposes a system where the origin
of any advertisement within BGP can be verified and authenticated,
preventing the advertisement of prefix blocks by unauthorized
networks, and verifying that the final destination in the path is
actually within the autonomous system to which the packets are being
routed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ng-sobgp-bgp-extensions-02.txt

__________________________________
[e-mail] CCIE <>< Grace Alone



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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA03769 for <[e-mail]>; Wed, 19 May 2004 20:25:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbJy-0006pA-Ew; Wed, 19 May 2004 20:22:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbBM-0004iB-Hr for [e-mail]; Wed, 19 May 2004 20:13:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00499 for <[e-mail]>; Wed, 19 May 2004 20:13:06 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQbBK-0000OS-En for [e-mail]; Wed, 19 May 2004 20:13:06 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQbAO-0000IM-00 for [e-mail]; Wed, 19 May 2004 20:12:08 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQbAF-0000CQ-00 for [e-mail]; Wed, 19 May 2004 20:11:59 -0400
Received: from cisco.com (shako.cisco.com [64.102.17.78]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4K0BR8R027936 for <[e-mail]>; Wed, 19 May 2004 17:11:28 -0700 (PDT)
Received: from localhost (rtp-vpn2-370.cisco.com [10.82.241.114]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA01603 for <[e-mail]>; Wed, 19 May 2004 20:11:27 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] New soBGP Drafts Published
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 19 May 2004 20:11:25 -0400 (Eastern Daylight Time)

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


	Title		: Architecture and Deployment Considerations for
Secure Origin BGP (soBGP)
	Author(s)	: R. White
	Filename	: draft-white-sobgparchitecture-00.txt
	Pages		: 11
	Date		: 2004-5-12

There is a great deal of concern over the security of the Border Gateway
Protocol, which is used to provide routing information to the Internet and
other large internetworks. This draft provides an architecture for a secure
distributed registry of routing information to address these concerns. The
draft begins with an overview of the operation of this system, and then
follows with various deployment scenerios, starting with what we believe
will be the most common deployment option.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-white-sobgparchitecture-00.txt

__________________________________
[e-mail] CCIE <>< Grace Alone



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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA19280 for <[e-mail]>; Wed, 19 May 2004 17:00:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXLP-0002Qt-P0; Wed, 19 May 2004 16:07:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWyw-0004NF-Qc for [e-mail]; Wed, 19 May 2004 15:44:02 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07640; Wed, 19 May 2004 15:44:00 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-04.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 19 May 2004 15:44:00 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Experience with the BGP-4 Protocol
	Author(s)	: D. McPherson, K. Patel
	Filename	: draft-ietf-idr-bgp4-experience-protocol-04.txt
	Pages		: 22
	Date		: 2004-5-19
	
The purpose of this memo is to document how the requirements for
   advancing a routing protocol from Draft Standard to full Standard
   have been satisfied by Border Gateway Protocol version 4 (BGP-4).

   This report satisfies the requirement for "the second report", as
   described in Section 6.0 of RFC 1264.  In order to fulfill the
   requirement, this report augments RFC 1773 and describes additional
   knowledge and understanding gained in the time between when the
   protocol was made a Draft Standard and when it was submitted for
   Standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ietf-idr-bgp4-experience-protocol-04.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-04.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.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-experience-protocol-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA19221 for <[e-mail]>; Wed, 19 May 2004 16:59:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXLO-0002Ql-Vr; Wed, 19 May 2004 16:07:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWyq-0004L1-QL for [e-mail]; Wed, 19 May 2004 15:43:56 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07614; Wed, 19 May 2004 15:43:54 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc3065bis-02.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 19 May 2004 15:43:54 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Autonomous System Confederations for BGP
	Author(s)	: P. Traina, et al.
	Filename	: draft-ietf-idr-rfc3065bis-02.txt
	Pages		: 15
	Date		: 2004-5-19
	
   The Border Gateway Protocol (BGP) is an inter-autonomous system
   routing protocol designed for Transmission Control Protocol/Internet
   Protocol (TCP/IP) networks.  BGP requires that all BGP speakers
   within a single autonomous system (AS) must be fully meshed.  This
   represents a serious scaling problem that has been well documented in
   a number of proposals.

   This document describes an extension to BGP which may be used to
   create a confederation of autonomous systems that is represented as a
   single autonomous system to BGP peers external to the confederation,
   thereby removing the "full mesh" requirement.  The intention of this
   extension is to aid in policy administration and reduce the
   management complexity of maintaining a large autonomous system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ietf-idr-rfc3065bis-02.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-rfc3065bis-02.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.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-rfc3065bis-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-rfc3065bis-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08501 for <[e-mail]>; Wed, 19 May 2004 14:56:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVnJ-0006Ux-LV; Wed, 19 May 2004 14:27:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQTBa-00082M-U3 for [e-mail]; Wed, 19 May 2004 11:40:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19150 for <[e-mail]>; Wed, 19 May 2004 11:40:48 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQTBZ-0006WL-M2 for [e-mail]; Wed, 19 May 2004 11:40:49 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQTAc-0006TA-00 for [e-mail]; Wed, 19 May 2004 11:39:50 -0400
Received: from [68.120.110.66] (helo=laptop2.kurtis.pp.se) by ietf-mx with esmtp (Exim 4.12) id 1BQTA4-0006PB-00 for [e-mail]; Wed, 19 May 2004 11:39:16 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 9D2A240F9F6; Wed, 19 May 2004 17:38:58 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=fixed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
From: Kurt Erik Lindqvist <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
To: Yakov Rekhter <[e-mail]>
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 19 May 2004 17:38:55 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 2004-05-18, at 15.56, Yakov Rekhter wrote:

> Kurt,
>
> Could you please clarify whether (a) you are in favor or against
> accepting signalled prefix limit as an IDR WG item, and if yes,
> then

I actually fail to see much value of this feature, but apparently 
others does. I more agree with Pedro and Tony. But I don't feel 
strongly one way or the other.

> (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
> or draft-keyur-prefixlimit-orf-00.txt) would you favor.
>

See above.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQKt/kaarNKXTPFCVEQJPbACg7XIBveDBQxYwJqJ2gTGa0mUxw4QAniio
r4cErtHgyvbwk7ABPax0qdJY
=LobO
-----END PGP SIGNATURE-----


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08474 for <[e-mail]>; Wed, 19 May 2004 14:56:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVnI-0006Uj-Th; Wed, 19 May 2004 14:27:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQT9c-0007Nz-7D for [e-mail]; Wed, 19 May 2004 11:38:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19091 for <[e-mail]>; Wed, 19 May 2004 11:38:45 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQT9b-0006PK-0C for [e-mail]; Wed, 19 May 2004 11:38:47 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQT8i-0006MS-00 for [e-mail]; Wed, 19 May 2004 11:37:53 -0400
Received: from [68.120.110.66] (helo=laptop2.kurtis.pp.se) by ietf-mx with esmtp (Exim 4.12) id 1BQT8F-0006J1-00 for [e-mail]; Wed, 19 May 2004 11:37:23 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 436BA40F9E3; Wed, 19 May 2004 17:37:04 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=fixed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: <[e-mail]>
From: Kurt Erik Lindqvist <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
To: "Susan Hares" <[e-mail]>
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 19 May 2004 17:36:54 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



> <wg chair hat on>
> All votes are welcomed and answer
> the standards question Yakov posed
> earlier.
>
> Not all votes indicated what will be
> deployed in networks or how.
>
> In our past email discussions, there have
> been many threads about making sure each
> new feature in bgp is really needed
> for operations of networks.
>
> <wg chair hat off>

Thanks. This just wasn't very clear from the question.

>
> <personal hat on>
> Running code and rough consensus for IETF
> usually means these questions are appropriate.
> Yes, I personally care what gets deployed and
> that network operators get the tools they need to run
> networks.   I've worked on operator forums
> (NANOG, etc) for over 15 years.
> <personal hat off>

So do I. But the discussion on who's a network operator and whos a 
vendor have been up before. From your original message, it was not 
clear to me why you asked.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQKt/GqarNKXTPFCVEQKT5QCg83ZMj0kTStsutLAivuZpMLp4EtUAoLc+
FK90/QqUQrCsU7pt3Qjj5IdW
=A8us
-----END PGP SIGNATURE-----


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA11953 for <[e-mail]>; Wed, 19 May 2004 10:30:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQRfu-0002k3-D7; Wed, 19 May 2004 10:04:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQRWx-0007zZ-DV for [e-mail]; Wed, 19 May 2004 09:54:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11536 for <[e-mail]>; Wed, 19 May 2004 09:54:44 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQRWv-0006A4-CC for [e-mail]; Wed, 19 May 2004 09:54:45 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQRW2-000683-00 for [e-mail]; Wed, 19 May 2004 09:53:50 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BQRVb-000658-00; Wed, 19 May 2004 09:53:23 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4JDqp959621; Wed, 19 May 2004 06:52:51 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4JDqkJ80739; Wed, 19 May 2004 06:52:46 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
cc: [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] rfc2796bis to Draft Standard
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 19 May 2004 06:52:46 -0700

Alex and Bill,

The IDR WG would like to ask the IESG to advance
draft-ietf-idr-rfc2796bis-01.txt to a Draft Standard.

The implementation report is in draft-chen-bgp-rfc2796bis-survey-00.txt.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA25955 for <[e-mail]>; Tue, 18 May 2004 17:03:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBWu-0002mZ-55; Tue, 18 May 2004 16:49:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQB4b-00016V-7v for [e-mail]; Tue, 18 May 2004 16:20:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13031 for <[e-mail]>; Tue, 18 May 2004 16:20:22 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQB4Z-0006Al-Gf for [e-mail]; Tue, 18 May 2004 16:20:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQB2N-0005o2-00 for [e-mail]; Tue, 18 May 2004 16:18:08 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BQAzr-0005E9-00 for [e-mail]; Tue, 18 May 2004 16:15:31 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4IKEvI31812; Tue, 18 May 2004 23:14:57 +0300
From: Pekka Savola <[e-mail]>
To: Yakov Rekhter <[e-mail]>
cc: [e-mail]
Subject: Re: prefix-limiting scenarios [RE: [Idr] signalled prefix limit as an IDR WG work item] 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 23:14:57 +0300 (EEST)

On Tue, 18 May 2004, Yakov Rekhter wrote:
> Could you please clarify whether (a) you are in favor or against
> accepting signalled prefix limit as an IDR WG item, and if yes,
> then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
> or draft-keyur-prefixlimit-orf-00.txt) would you favor.

I'm against accepting prefix limit signalling at this point, though 
not strongly.

These are not strictly required, and we don't have sufficient
understanding/agreement on the different approaches yet.

Different people seem to have way too different opinions on what the
two specific approaches actually entail and what are their
differences.  Even if we chose to go for prefix limit signalling, I'd
have to object at this point to taking either as a WG work item.  We
need to clarify draft-chavali in particular a lot first, so that we
can start talking about different kinds of apples, rather than apples
and oranges.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA10557 for <[e-mail]>; Tue, 18 May 2004 14:27:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ93V-0003zA-OC; Tue, 18 May 2004 14:11:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8ty-0001fI-Fs for [e-mail]; Tue, 18 May 2004 14:01:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01841 for <[e-mail]>; Tue, 18 May 2004 14:01:16 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8tw-0003W0-3Z for [e-mail]; Tue, 18 May 2004 14:01:16 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8tB-0003TP-00 for [e-mail]; Tue, 18 May 2004 14:00:29 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BQ8sf-0003PL-00 for [e-mail]; Tue, 18 May 2004 13:59:57 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4IHxRBm021256 for <[e-mail]>; Tue, 18 May 2004 10:59:27 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4IHxRJ49916 for <[e-mail]>; Tue, 18 May 2004 10:59:27 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 10:59:27 -0700

Folks,

There is a consensus to accept draft-chen-bgp-avoid-transition-01.txt
as an IDR WG document with the following change.

After

   As a result, it
   can be used as a simple and efficient tool to eliminate certain
   permanent ibgp route oscillation [3].

add the following text:

  Note however, that there are permanent ibgp route oscillation
  scenarios that the mechanism described in this document does not
  eliminate.

With this in mind I'd like the authors of the document to make this 
change and then re-submit it as an IDR WG document.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07129 for <[e-mail]>; Tue, 18 May 2004 13:54:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8k3-0008VR-00; Tue, 18 May 2004 13:51:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8XZ-0006I8-UZ for [e-mail]; Tue, 18 May 2004 13:38:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29763 for <[e-mail]>; Tue, 18 May 2004 13:38:07 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8XX-0001kU-Lw for [e-mail]; Tue, 18 May 2004 13:38:07 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8Wi-0001iV-00 for [e-mail]; Tue, 18 May 2004 13:37:17 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BQ8Vq-0001eC-00 for [e-mail]; Tue, 18 May 2004 13:36:22 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4IHZq955385 for <[e-mail]>; Tue, 18 May 2004 10:35:52 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4IHZlJ46595 for <[e-mail]>; Tue, 18 May 2004 10:35:47 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] prefix limit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 10:35:47 -0700

Folks,

For the purpose of determining the WG consensus on the attached I
assume that (a) everyone who replies "yes" to either (2) or (3) is
also in favor of taking signalling prefix limit as a WG item, and
(b) co-authors of each proposal are in favor of accepting that
proposal as a WG item (unless they explicitly state otherwise).

Yakov.

P.S. One could say that the above is obvious, but the reason I am
stating the above is to avoid any misunderstanding.
------- Forwarded Message

Date:    Tue, 11 May 2004 19:35:54 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
Subject: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document

Folks,

Given the current discussion on the mailing list, the deadline
for comments on accepting draft-chavali-bgp-prefixlimit-02.txt
as an IDR WG document is extended to May 24, 2004.

This way May 24 is the deadline for comments on the following:

1. whether to take signalled prefix limit as a WG item

2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR
   WG document

3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR
   WG document

In your e-mails please clearly indicate your preferences. Providing
rationale for your preferences would be extremely useful as well.

Yakov.

P.S If folks feel that the deadline should be extended beyond
May 24, please say so.

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

------- End of Forwarded Message


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA05786 for <[e-mail]>; Tue, 18 May 2004 13:41:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8TZ-0005Xn-PM; Tue, 18 May 2004 13:34:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8Lv-0003jX-Su for [e-mail]; Tue, 18 May 2004 13:26:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29114 for <[e-mail]>; Tue, 18 May 2004 13:26:06 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8Lt-00015E-Sy for [e-mail]; Tue, 18 May 2004 13:26:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8Kw-00012W-00 for [e-mail]; Tue, 18 May 2004 13:25:07 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ8Kf-0000ze-00 for [e-mail]; Tue, 18 May 2004 13:24:49 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D67492D49DE; Tue, 18 May 2004 13:24:13 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 92140-01-20; Tue, 18 May 2004 13:24:01 -0400 (EDT)
Received: from aa-backup1.nexthop.com (aa-backup1.nexthop.com [65.247.36.118]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 873852D48C0; Tue, 18 May 2004 13:24:01 -0400 (EDT)
Received: (from jhaas@localhost) by aa-backup1.nexthop.com (8.11.6/8.11.6) id i4IHO1Y06797; Tue, 18 May 2004 13:24:01 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 13:24:01 -0400

I have been asked for clarification of my abstention off-list especially
given previous on-list comments.

Of the two approaches, I favor chavali for two reasons:
1. Multiple prefix-limit threshholds.
2. Active signaling when a threshhold is crossed.

I do have concerns about each of the proferred signaling mechanisms
(dynamic capability vs. ORF).  I would like to see these issues
worked through before people start writing code.

So, if the question is which of the general approaches (apart from
implementation or on the wire signalling) I prefer, chavali would have
my vote.

On Tue, May 18, 2004 at 09:56:53AM -0400, Jeffrey Haas wrote:
> Yakov,
> 
> On Tue, May 18, 2004 at 06:53:08AM -0700, Yakov Rekhter wrote:
> > Could you please clarify whether (a) you are in favor or against
> > accepting signalled prefix limit as an IDR WG item, and if yes,
> > then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
> > or draft-keyur-prefixlimit-orf-00.txt) would you favor.
> 
> a - I am in favor of this as a IDR WG item.
> b - I am abstaining from either approach.
> 
> > Yakov.
> 
> -- 
> Jeff Haas 
> NextHop Technologies

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03004 for <[e-mail]>; Tue, 18 May 2004 13:14:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7ze-00060W-IH; Tue, 18 May 2004 13:03:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7mH-0002M4-6S for [e-mail]; Tue, 18 May 2004 12:49:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27048 for <[e-mail]>; Tue, 18 May 2004 12:49:13 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ7mF-0006cM-Ah for [e-mail]; Tue, 18 May 2004 12:49:15 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ7lE-0006YA-00 for [e-mail]; Tue, 18 May 2004 12:48:12 -0400
Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BQ7ka-0006Of-00 for [e-mail]; Tue, 18 May 2004 12:47:32 -0400
Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <[e-mail]> for [e-mail]; Tue, 18 May 2004 16:47:02 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <[e-mail]>; Tue, 18 May 2004 16:47:01 +0000 (GMT)
Received: from WS344V8066292 ([153.39.146.163]) by pmismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <[e-mail]>; Tue, 18 May 2004 16:46:30 +0000 (GMT)
From: Parantap Lahiri <[e-mail]>
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item
In-reply-to: <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Message-id: <000e01c43cf7$aba718e0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook, Build 10.0.4510
Content-type: text/plain; charset=us-ascii
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 12:46:30 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA03004

(a) I am against accepting signaled prefix as a WG item. Concurring with
Pedro, I think the problem space has to be better understood in its entirety
and the benefits of this new complexity have to be more clearly established.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Yakov
Rekhter
Sent: Tuesday, May 18, 2004 9:55 AM
To: Parantap Lahiri
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item

Parantap,

Could you please clarify whether (a) you are in favor or against
accepting signalled prefix limit as an IDR WG item, and if yes,
then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
or draft-keyur-prefixlimit-orf-00.txt) would you favor.

Yakov.

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


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA01535 for <[e-mail]>; Tue, 18 May 2004 13:00:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7jG-0001gP-Ss; Tue, 18 May 2004 12:46:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7Zb-00076b-5E for [e-mail]; Tue, 18 May 2004 12:36:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26090 for <[e-mail]>; Tue, 18 May 2004 12:36:08 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ7ZZ-0005gh-GI for [e-mail]; Tue, 18 May 2004 12:36:09 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ7Yf-0005c1-00 for [e-mail]; Tue, 18 May 2004 12:35:14 -0400
Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BQ7Xb-0005XL-00 for [e-mail]; Tue, 18 May 2004 12:34:07 -0400
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7B0AF330A44; Tue, 18 May 2004 09:34:06 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08328-08; Tue, 18 May 2004 09:34:06 -0700 (PDT)
Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 20843330A43; Tue, 18 May 2004 09:34:06 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 68B2A979C1; Tue, 18 May 2004 09:34:03 -0700 (PDT)
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
In-Reply-To: Message from Yakov Rekhter <[e-mail]>  of "Tue, 11 May 2004 19:35:54 PDT." <[e-mail]> 
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 09:34:03 -0700

> Message-Id: <[e-mail]>
> To: [e-mail]
> Subject: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
> From: Yakov Rekhter <[e-mail]>
> Sender: [e-mail]
> Date: Tue, 11 May 2004 19:35:54 -0700

> Folks,
> 
> Given the current discussion on the mailing list, the deadline
> for comments on accepting draft-chavali-bgp-prefixlimit-02.txt
> as an IDR WG document is extended to May 24, 2004.
> 
> This way May 24 is the deadline for comments on the following:
> 
> 1. whether to take signalled prefix limit as a WG item

Yes.

Let us assume that the prefix limit is configured on the provider side,
it seems to be useful for the customer side to generate a warning before
the prefix limit is reached. The warning hopefully would give the customer
an opportunity to check its routing table, and initiate discussion with the
provider to raise the limit.

Once the prefix limit is reached, the BGP session should be dropped.
I do not see a cost effective way to make "selective" update drop work.

> 
> 2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR
>    WG document
> 
> 3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR
>    WG document

I am in favor of draft-keyur-prefixlimit-orf-00.txt as it is simpler,
and ORF mechanism itself is a mature and well-understood technology.

-- Enke


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA29905 for <[e-mail]>; Tue, 18 May 2004 12:45:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7Uc-00052w-VU; Tue, 18 May 2004 12:31:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7K5-0002EC-IS for [e-mail]; Tue, 18 May 2004 12:20:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25363 for <[e-mail]>; Tue, 18 May 2004 12:20:06 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ7K4-0004lN-4H for [e-mail]; Tue, 18 May 2004 12:20:08 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ7J5-0004j7-00 for [e-mail]; Tue, 18 May 2004 12:19:08 -0400
Received: from [209.172.119.155] (helo=soln-sro177.solutionip.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ7IP-0004gi-00 for [e-mail]; Tue, 18 May 2004 12:18:25 -0400
Received: from [209.172.91.155] (helo=[209.172.91.155]) by soln-sro177.solutionip.com with esmtp (Exim 3.34 #1) id 1BQ7Hc-0004eZ-00; Tue, 18 May 2004 09:17:36 -0700
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: Keyur Patel <[e-mail]>
From: Danny McPherson <[e-mail]>
To: idr <[e-mail]>
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Idr] BGP Protocol Experience Draft (-04)
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 10:17:35 -0600

I just posted an update version of the BGP Protocol Experience
draft.  Not much changed, here's a diff from the -03 revision,
the new version (-04) should be available in the Internet-Drafts
repository RSN.

Not sure if it needs to relive WG LC or not..

-danny



< Expires: March 2004                           September 2003
---
 > Expires: November 2004                              May 2004
10c10
<             <draft-ietf-idr-bgp4-experience-protocol-03.txt>
---
 >             <draft-ietf-idr-bgp4-experience-protocol-04.txt>
45c45
<    Copyright (C) The Internet Society (2003). All Rights Reserved.
---
 >    Copyright (C) The Internet Society (2004). All Rights Reserved.
54c54
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
110c110
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
120c120
<    4. Implementations. . . . . . . . . . . . . . . . . . . . . . . .  
  5
---
 >    4. Implementation Information . . . . . . . . . . . . . . . . . .  
  5
129c129
<    8. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . .  
  9
---
 >    8. Local Preference . . . . . . . . . . . . . . . . . . . . . . .  
  9
135c135
<     13.1. Consideration of TCP Characteristics . . . . . . . . . . .  
13
---
 >     13.1. Consideration of TCP Characteristics . . . . . . . . . . .  
14
140c140
<     17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . .  
15
---
 >     17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . .  
16
142c142
<     17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . .  
16
---
 >     17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . .  
17
146c146
<     A Bit of History . . . . . . . . . . . . . . . . . . . . . . . .  
17
---
 >     A Bit of History . . . . . . . . . . . . . . . . . . . . . . . .  
18
166c166
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
222c222
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
243c243
< 4.  Implementations
---
 > 4.  Implementation Information
278c278
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
287c287
<    Confederations for BGP, and perhaps some mix of the two.  BGP Route
---
 >    Confederations for BGP, and often some mix of the two.  BGP Route
305c305
<    120,000 aggregate entries, representing several times that number 
of
---
 >    134,000 aggregate entries, representing several times that number 
of
307c307
<    provider core routers exceeds 2.5 million.  Native AS_PATH lengths
---
 >    provider core routers exceeds 2.5 million.  Native AS path lengths
309c309
<    more ASs exist.
---
 >    more autonomous systems exist.
334c334
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
341,342c341,342
<    is used as a metric by EBGP peers while BGP Local Preference is 
used
<    by IBGP peers.
---
 >    is used as a metric by EBGP peers (i.e., inter-domain) while Local
 >    Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain).
358c358
<    different ASs as well.
---
 >    different autonomous systems as well.
366,371c366,371
<    between multiple paths learned from a single AS, it can result in
<    potentially bad decisions when comparing MEDs between different
<    automomous systems.  This is most typically the case when the
<    autonomous systems use different mechanisms to derive IGP metrics,
<    BGP MEDs, or perhaps even use different IGP procotols with vastly
<    contrasting metric spaces.
---
 >    between multiple paths learned from a single adjacent AS, it can
 >    result in potentially bad decisions when comparing MEDs between
 >    different automomous systems.  This is most typically the case when
 >    the autonomous systems use different mechanisms to derive IGP
 >    metrics, BGP MEDs, or perhaps even use different IGP procotols with
 >    vastly contrasting metric spaces.
390c390
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
430a431,434
 >    Seemingly more intuitive references that fall outside the vegetable
 >    kingdom refer to cold potatoe routing as "best exit routing", and 
hot
 >    potatoe routing as "closest exit routing", though vegetable.
 >
437,440d440
<    be passed to its IBGP peers.  Although advertising MEDs to IBGP 
peers
<    is not a required behavior, it is a common default.  MEDs received
<    from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP
<    peers.
446c446
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
448a449,453
 >    be passed to its IBGP peers.  Although advertising MEDs to IBGP 
peers
 >    is not a required behavior, it is a common default.  MEDs received
 >    from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP
 >    peers.
 >
459,462c464,467
<    An implementation MUST provide a mechanism that allows for MED to 
be
<    removed.  Previously, implementations did not consider a missing 
MED
<    value to be the same as a MED of zero.  No MED value should now be
<    equal to a value of zero.
---
 >    [BGP4] requires that an implementation must provide a mechanism 
that
 >    allows for MED to be removed.  Previously, implementations did not
 >    consider a missing MED value to be the same as a MED of zero.  
[BGP4]
 >    now requires that no MED value be equal to a value of zero.
464c469
<    Note that many implementations provide an mechanism to explicitly
---
 >    Note that many implementations provide a mechanism to explicitly
479c484
<    non-deterministic behavior, and as such, is often undesirable.
---
 >    non-deterministic behavior, and as such, may often be undesirable.
483c488
< 8.  LOCAL_PREF
---
 > 8.  Local Preference
492,496d496
<    default value of LOCAL-PREF to be assumed if none was provided.
<    Defaults of 0 or the maximum value each have range limitations, so 
a
<    common default would aid in the interoperation of multi-vendor
<    routers in the same AS (since LOCAL_PREF is a local administration
<    knob, there is no interoperability drawback across AS boundaries).
502c502
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
505,507c505,514
<    The LOCAL_PREF MUST be sent to IBGP Peers.  The LOCAL_PREF 
Attribute
<    MUST NOT be sent to EBGP Peers.  Although no default value for
<    LOCAL_PREF is defined, the common default value is 100.
---
 >    default value of LOCAL_PREF to be assumed if none was provided.
 >    Defaults of 0 or the maximum value each have range limitations, so 
a
 >    common default would aid in the interoperation of multi-vendor
 >    routers in the same AS (since LOCAL_PREF is a local administration
 >    attribute, there is no interoperability drawback across AS
 >    boundaries).
 >
 >    [BGP4] requires that LOCAL_PREF be sent to IBGP Peers and must not 
be
 >    sent to EBGP Peers.  Although no default value for LOCAL_PREF is
 >    defined, the common default value is 100.
526c533
<    possibility of carrying an optional vector corresponding to the AS-
---
 >    possibility of carrying an optional vector corresponding to the AS_
528,534c535,542
<    given route.  Cooperating ASs may then chose traffic based upon
<    comparison of "interesting" portions of this vector according to
<    routing policy.
<
<    While protecting a given ASs routing policy is of paramount 
concern,
<    avoiding extensive hand configuration of routing policies needs to 
be
<    examined more carefully in future BGP-like protocols.
---
 >    given route.  Cooperating autonomous systems may then chose traffic
 >    based upon comparison of "interesting" portions of this vector
 >    according to routing policy.
 >
 >    While protecting a given autonoumous systems routing policy is of
 >    paramount concern, avoiding extensive hand configuration of routing
 >    policies needs to be examined more carefully in future BGP-like
 >    protocols.
545,552d552
<    information to all other transit and border routers within that AS.
<    This is typically done by establishing internal BGP connections to
<    all transit and border routers in the local AS.
<
<    Note that the number of BGP peers that can be fully meshed depends 
on
<    a number of factors, to include number of prefixes in the routing
<    system, stability of the system, and perhaps most importantly,
<    implementation ifficiency.  As a result, although it's difficult to
558c558
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
561,562c561,570
<    define "a large number of peers", there is always some practical
<    limit.
---
 >    information to all other transit and border routers within that AS.
 >    This is typically done by establishing internal BGP connections to
 >    all transit and border routers in the local AS.
 >
 >    Note that the number of BGP peers that can be fully meshed depends 
on
 >    a number of factors, to include number of prefixes in the routing
 >    system, number of unique path, stability of the system, and perhaps
 >    most importantly, implementation efficiency.  As a result, although
 >    it's difficult to define "a large number of peers", there is always
 >    some practical limit.
582,583c590,591
<    Internet.  As the net has grown, the number of route changes per
<    second has increased.
---
 >    Internet.  As the Internet has grown, the frequency of route 
changes
 >    per second has increased.
600c608,616
<    manditory in RFC 2439.  A potential result of failure to consider
---
 >    mandatory in RFC 2439.  A potential result of failure to consider
 >
 >
 >
 > McPherson, Patel                                  Section 10.  [Page 
11]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
609,620c625,628
<
<
<
< McPherson, Patel                                  Section 10.  [Page 
11]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
<    changes to be announced are inefficiently packed.  As previously
<    discussed, announcing routing changes sharing common attributes in 
a
<    single BGP UPDATE message helps save considerable bandwidth and 
lower
<    processing overhead.
---
 >    changes to be announced are inefficiently packed.  As discussed in 
a
 >    later section, announcing routing changes sharing common attributes
 >    in a single BGP UPDATE message helps save considerable bandwidth 
and
 >    lower processing overhead.
656a665,672
 >
 >
 >
 > McPherson, Patel                                  Section 12.  [Page 
12]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
665,672d680
<
<
<
< McPherson, Patel                                  Section 12.  [Page 
12]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
712a721,728
 >
 >
 >
 > McPherson, Patel                                  Section 13.  [Page 
13]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
721,728d736
<
<
<
< McPherson, Patel                                Section 13.1.  [Page 
13]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
738,741c746,749
<    buffer can grow until memory is exhausted.  A BGP implementation 
must
<    send changes to all peers for which the TCP connection is not 
blocked
<    and must remember to send those changes to the remaining peers when
<    the connection becomes unblocked.
---
 >    buffer can grow until memory is exhausted.  A BGP implementation is
 >    required to send changes to all peers for which the TCP connection 
is
 >    not blocked and is required to remember to send those changes to 
the
 >    remaining peers when the connection becomes unblocked.
769,773d776
<    Implementers may find it useful to order path attributes according 
to
<    Type Code so that sets of attributes with identical semantics can 
be
<    more quickly identified.
<
<
776a780,782
 > McPherson, Patel                                  Section 14.  [Page 
14]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
778a785,787
 >    Implementers may find it useful to order path attributes according 
to
 >    Type Code so that sets of attributes with identical semantics can 
be
 >    more quickly identified.
780,782d788
< McPherson, Patel                                  Section 14.  [Page 
14]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
802c808,810
<    to BGP-4 should provide the version support on a per-peer basis.
---
 >    to BGP-4 should provide the version support on a per-peer basis.  
At
 >    the time of this writing all BGP speakers on the Internet are 
thought
 >    to be running BGP version 4.
822a831,840
 >
 >
 >
 >
 >
 > McPherson, Patel                                  Section 17.  [Page 
15]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
833,840d850
<
<
<
< McPherson, Patel                                Section 17.1.  [Page 
15]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
844a855,867
 >    It was naively assumed by many for some time that in order to 
inject
 >    a data segement or reset a TCP transport connection between two BGP
 >    peers an attacker must correctly guess the exact TCP sequence 
number
 >    (of course, in addition to source and destination ports and IP
 >    addresses).  However, it has recently been observed and openly
 >    discussed that the malicous data only needs to fall within the TCP
 >    receive window, which may be quite large, thereby significantly
 >    lowering the complexity of such an attack.
 >
 >    As such, it is recommended that the MD5 TCP Signature Option be
 >    employed to protect BGP from session resets and malicious data
 >    injection.
 >
867a891,896
 >
 > McPherson, Patel                                Section 17.2.  [Page 
16]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
888,896d916
<
<
<
<
< McPherson, Patel                                Section 17.3.  [Page 
16]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
924a945,952
 >
 >
 >
 > McPherson, Patel                                Section 17.5.  [Page 
17]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
946,952d973
<
<
< McPherson, Patel                                Section 17.6.  [Page 
17]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
979a1001,1008
 >
 >
 >
 > McPherson, Patel                                Section 17.6.  [Page 
18]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
1004,1008d1032
< McPherson, Patel                                Section 17.6.  [Page 
18]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
1036,1059d1059
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
1062c1062
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
1118c1118
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
1139c1139,1140
<    [BGP4-ANALYSIS] Work in Progress.
---
 >    [BGP4-ANALYSIS] "BGP-4 Protocol Analysis", Internet-Draft, Work in
 >               Progress.
1141c1142,1143
<    [BGP4-IMPL] Work in Progress.
---
 >    [BGP4-IMPL] "BGP 4 Implementation Report ", Internet-Draft, Work
 >               in Progress.
1146c1148
<    [SBGP]
---
 >    [SBGP]  "Secure BGP", Internet-Draft, Work in Progress.
1148c1150
<    [soBGP]
---
 >    [soBGP] "Secure Origin BGP", Internet-Draft, Work in Progress.
1170,1171d1171
<
<
1174c1174
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
1179c1179
<    Copyright (C) The Internet Society (2003). All Rights Reserved.
---
 >    Copyright (C) The Internet Society (2004). All Rights Reserved.


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24775 for <[e-mail]>; Tue, 18 May 2004 11:55:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6m6-0006Zr-AK; Tue, 18 May 2004 11:45:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6eR-0003s7-7e for [e-mail]; Tue, 18 May 2004 11:37:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23262 for <[e-mail]>; Tue, 18 May 2004 11:37:04 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ6eQ-0002N4-3R for [e-mail]; Tue, 18 May 2004 11:37:06 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ6dY-0002KA-00 for [e-mail]; Tue, 18 May 2004 11:36:12 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BQ6cv-0002Fi-00 for [e-mail]; Tue, 18 May 2004 11:35:33 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 18 May 2004 08:35:17 -0700
X-BrightmailFiltered: true
Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4IFYxpI007452; Tue, 18 May 2004 11:34:59 -0400 (EDT)
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
cc: [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
In-reply-to: Your message of Tue, 18 May 2004 06:51:11 -0700. <[e-mail]> 
Reply-To: [e-mail]
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
From: Eric Rosen <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 11:35:00 -0400

> Could you please clarify whether (a) you are in favor or against
> accepting signalled prefix limit as an IDR WG item,

In favor.  

> if yes,
> then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
> or draft-keyur-prefixlimit-orf-00.txt) would you favor. 

draft-keyur. 


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20411 for <[e-mail]>; Tue, 18 May 2004 11:09:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ64Y-0002lp-Ep; Tue, 18 May 2004 11:00:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5uS-0008H9-Kn for [e-mail]; Tue, 18 May 2004 10:49:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20355 for <[e-mail]>; Tue, 18 May 2004 10:49:32 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5uP-0007CS-I0 for [e-mail]; Tue, 18 May 2004 10:49:33 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5tA-000755-00 for [e-mail]; Tue, 18 May 2004 10:48:17 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ5sf-00070e-00 for [e-mail]; Tue, 18 May 2004 10:47:45 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D7D832D480C; Tue, 18 May 2004 10:47:15 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 86703-01-55; Tue, 18 May 2004 10:47:04 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 588602D48A6; Tue, 18 May 2004 10:47:04 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i4IEl2X14034; Tue, 18 May 2004 10:47:02 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], Tony Li <[e-mail]>, "Naidu, Venkata" <[e-mail]>, [e-mail]
Subject: Re: [Idr] proposed additional text
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, May 18, 2004 at 07:34:03AM -0700
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 10:47:01 -0400

Yakov,

Estimations such as these are based on current levels of traffic
on the BGP session.  While this estimate is good for now, will it
be good later on?  My suspicion is no, although it will still probably
be in the window of a day or more for the next decade.

IMO, we should simply recommend good keying practices, not talk
about the rekeying interval (or leave to another document) and
simply note the vulnerability.  If we feel the need to say that
we consider this to be a small one as of the time of this writing,
that's fine.

On Tue, May 18, 2004 at 07:34:03AM -0700, Yakov Rekhter wrote:
> How about if we'll replace
> 
>    Because the mechanism defined in RFC 2385 does not
>    provide peer-entity authentication, these connections are still
>    subject to some forms of replay attacks.
> 
> with the following
> 
>    Because the mechanism defined in RFC 2385 does not provide
>    peer-entity authentication, these connections are still subject
>    to some forms of replay attacks. Changing key more frequently
>    (e.g., once a week or more) reduces the probability of such
>    attacks.  Determining whether such attacks could happen in
>    practice is outside the scope of this document.
> 
> Yakov.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA19067 for <[e-mail]>; Tue, 18 May 2004 10:56:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5t4-0007t1-B6; Tue, 18 May 2004 10:48:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5hR-0002ZR-W3 for [e-mail]; Tue, 18 May 2004 10:36:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19554 for <[e-mail]>; Tue, 18 May 2004 10:36:06 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5hP-00069U-M1 for [e-mail]; Tue, 18 May 2004 10:36:07 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5ge-00064b-00 for [e-mail]; Tue, 18 May 2004 10:35:21 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BQ5g5-0005vh-00 for [e-mail]; Tue, 18 May 2004 10:34:45 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4IEY4Bm020548; Tue, 18 May 2004 07:34:04 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4IEY3J21413; Tue, 18 May 2004 07:34:03 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
cc: Tony Li <[e-mail]>, "Naidu, Venkata" <[e-mail]>, [e-mail], Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] proposed additional text 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 07:34:03 -0700

Folks,

How about if we'll replace

   Because the mechanism defined in RFC 2385 does not
   provide peer-entity authentication, these connections are still
   subject to some forms of replay attacks.

with the following

   Because the mechanism defined in RFC 2385 does not provide
   peer-entity authentication, these connections are still subject
   to some forms of replay attacks. Changing key more frequently
   (e.g., once a week or more) reduces the probability of such
   attacks.  Determining whether such attacks could happen in
   practice is outside the scope of this document.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA16007 for <[e-mail]>; Tue, 18 May 2004 10:23:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5DL-0006mO-Qj; Tue, 18 May 2004 10:05:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ58C-0003LY-UK for [e-mail]; Tue, 18 May 2004 09:59:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15352 for <[e-mail]>; Tue, 18 May 2004 09:59:42 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ58A-0007hg-VG for [e-mail]; Tue, 18 May 2004 09:59:43 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ56p-0007IY-00 for [e-mail]; Tue, 18 May 2004 09:58:20 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ567-0006t5-00 for [e-mail]; Tue, 18 May 2004 09:57:35 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 684C32D48A6; Tue, 18 May 2004 09:57:05 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 85851-01-32; Tue, 18 May 2004 09:56:53 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4CE102D4870; Tue, 18 May 2004 09:56:53 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i4IDurs13891; Tue, 18 May 2004 09:56:53 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, May 18, 2004 at 06:53:08AM -0700
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 09:56:53 -0400

Yakov,

On Tue, May 18, 2004 at 06:53:08AM -0700, Yakov Rekhter wrote:
> Could you please clarify whether (a) you are in favor or against
> accepting signalled prefix limit as an IDR WG item, and if yes,
> then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
> or draft-keyur-prefixlimit-orf-00.txt) would you favor.

a - I am in favor of this as a IDR WG item.
b - I am abstaining from either approach.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15979 for <[e-mail]>; Tue, 18 May 2004 10:23:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5DK-0006ln-JT; Tue, 18 May 2004 10:05:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ587-0003IH-BU for [e-mail]; Tue, 18 May 2004 09:59:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15343 for <[e-mail]>; Tue, 18 May 2004 09:59:36 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ585-0007hI-CT for [e-mail]; Tue, 18 May 2004 09:59:37 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ56j-0007I0-00 for [e-mail]; Tue, 18 May 2004 09:58:14 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BQ55w-0006fJ-00 for [e-mail]; Tue, 18 May 2004 09:57:24 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4IDusBm020423; Tue, 18 May 2004 06:56:54 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4IDurJ16824; Tue, 18 May 2004 06:56:54 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kurt Erik Lindqvist <[e-mail]>
cc: [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
In-Reply-To: Your message of "Mon, 17 May 2004 16:37:51 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 06:56:53 -0700

Kurt,

Could you please clarify whether (a) you are in favor or against
accepting signalled prefix limit as an IDR WG item, and if yes,
then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
or draft-keyur-prefixlimit-orf-00.txt) would you favor.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15924 for <[e-mail]>; Tue, 18 May 2004 10:22:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5CT-0005pZ-5s; Tue, 18 May 2004 10:04:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ55p-0002n1-NX for [e-mail]; Tue, 18 May 2004 09:57:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15228 for <[e-mail]>; Tue, 18 May 2004 09:57:14 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ55n-0006tp-OD for [e-mail]; Tue, 18 May 2004 09:57:15 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ54v-0006Wp-00 for [e-mail]; Tue, 18 May 2004 09:56:21 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BQ54K-00068O-00 for [e-mail]; Tue, 18 May 2004 09:55:44 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4IDtDBm020417; Tue, 18 May 2004 06:55:13 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4IDtDJ16567; Tue, 18 May 2004 06:55:13 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Parantap Lahiri <[e-mail]>
cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item 
In-Reply-To: Your message of "Wed, 12 May 2004 11:53:18 EDT." <002501c43839$3e9574d0$[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 06:55:13 -0700

Parantap,

Could you please clarify whether (a) you are in favor or against
accepting signalled prefix limit as an IDR WG item, and if yes,
then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
or draft-keyur-prefixlimit-orf-00.txt) would you favor.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15818 for <[e-mail]>; Tue, 18 May 2004 10:21:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5CR-0005nK-HQ; Tue, 18 May 2004 10:04:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ53u-00021X-2h for [e-mail]; Tue, 18 May 2004 09:55:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15161 for <[e-mail]>; Tue, 18 May 2004 09:55:15 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ53s-00068W-4b for [e-mail]; Tue, 18 May 2004 09:55:16 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ532-0005lB-00 for [e-mail]; Tue, 18 May 2004 09:54:25 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BQ52J-0005NH-00 for [e-mail]; Tue, 18 May 2004 09:53:39 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4IDr8Bm020402; Tue, 18 May 2004 06:53:08 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4IDr8J16289; Tue, 18 May 2004 06:53:08 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item 
In-Reply-To: Your message of "Mon, 10 May 2004 10:55:50 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 06:53:08 -0700

Jeff,

> Yakov,
> 
> On Mon, May 10, 2004 at 07:17:53AM -0700, Yakov Rekhter wrote:
> > As we discuss relative merits of two approaches to signal prefix
> > limit, draft-chavali-bgp-prefixlimit-02.txt and
> > draft-keyur-prefixlimit-orf-00.txt, we also need to step back and
> > ask whether there is a WG consensus to take signalled prefix limit
> > as a work item.
> 
> I haven't had the opportunity to review the merits of either of
> these documents, but speaking with my hat as BGP MIB editor, one
> of the most requested features out of the V2 MIB has been better
> counters for prefixes on a per-AFI/SAFI basis.
> 
> A signaled prefix limit mechanism of some sort seems like it would
> also help fill this need.  The MIB allows localized management
> of the limits, a singalling mechanism allows one to communicate
> localized policy.
> 
> Regardless of the approach, the thing that has been mentioned during
> discussion of this issue has been, "Why do we care?"  Prefix limits
> are similar to other elements of BGP policy almost all of which have
> previously been local matters.  
> 
> The primary difference with prefix-limits has been that simply
> discarding prefixes as a local matter is not as operationally
> serious as one of the other mechanisms of dealing with the problem:
> dropping the peering session.  Both mechanisms are operationally
> disruptive, but dropping the session is probably even more so.
> 
> I think we should spend some of our time discussing the consequences
> of each of these actions regardless of the fact that each practice
> is currently well deployed.  Answering how we believe we should
> behave in these circumstances will probably help determine our behavior
> in any signalled prefix limit mechanism.

Could you please clarify whether (a) you are in favor or against
accepting signalled prefix limit as an IDR WG item, and if yes,
then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
or draft-keyur-prefixlimit-orf-00.txt) would you favor.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15704 for <[e-mail]>; Tue, 18 May 2004 10:20:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5CP-0005lI-EC; Tue, 18 May 2004 10:04:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ51r-0001AA-I5 for [e-mail]; Tue, 18 May 2004 09:53:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15066 for <[e-mail]>; Tue, 18 May 2004 09:53:08 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ51p-0005NN-LH for [e-mail]; Tue, 18 May 2004 09:53:09 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ50z-00050s-00 for [e-mail]; Tue, 18 May 2004 09:52:17 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BQ50U-0004eI-00 for [e-mail]; Tue, 18 May 2004 09:51:46 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4IDpG954443; Tue, 18 May 2004 06:51:16 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4IDpBJ16083; Tue, 18 May 2004 06:51:11 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
In-Reply-To: Your message of "Mon, 17 May 2004 13:00:48 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 06:51:11 -0700

Eric,

> > In the current implementation, the  prefix limit is only configured on the
> > BGP receiver (e.g., provider edge router), the BGP speaker (e.g. CPE) does
> > not  have   any  control.   Some  implementation  has   warning  threshold
> > option. When warning  limit is reached, the trap will only  show up on the
> > provider  side, the  operator  has to  contact  the customer  by phone  or
> > through some messaging systems.  
> 
> This suggests that it is useful for  a BGP speaker to know that a given peer
> will only be  able to receive n prefixes.  In that  case, it certainly makes
> sense for  the value  n to be  learned dynamically.   Both of the  drafts in
> question support that functionality. 
> 
> I don't see the argument  for dynamically learning multiple threshold levels
> from a peer.  Especially as there  are no real semantics associated with the
> other thresholds. 

Could you please clarify whether (a) you are in favor or against
accepting signalled prefix limit as an IDR WG item, and if yes,
then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
or draft-keyur-prefixlimit-orf-00.txt) would you favor.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15580 for <[e-mail]>; Tue, 18 May 2004 10:19:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5CO-0005kF-Fn; Tue, 18 May 2004 10:04:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ51i-00019r-Qs for [e-mail]; Tue, 18 May 2004 09:53:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15052 for <[e-mail]>; Tue, 18 May 2004 09:53:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ51g-0005ME-Tg for [e-mail]; Tue, 18 May 2004 09:53:01 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ50k-0004zV-00 for [e-mail]; Tue, 18 May 2004 09:52:02 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BQ4zn-0004Hf-00 for [e-mail]; Tue, 18 May 2004 09:51:03 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4IDoW954439; Tue, 18 May 2004 06:50:32 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4IDoRJ16019; Tue, 18 May 2004 06:50:27 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pekka Savola <[e-mail]>
cc: [e-mail]
Subject: Re: prefix-limiting scenarios [RE: [Idr] signalled prefix limit as an IDR WG work item] 
In-Reply-To: Your message of "Wed, 12 May 2004 07:56:43 +0300." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 06:50:27 -0700

Pekka,

> Let's try to figure out the scenarios for prefix-limits a bit better..
> 
> As to where we use prefix-limits.. toward peers (but not
> upstreams/customers).  For customers, we have strict prefix list; for
> upstreams, we don't want to filter out anything -- so nothing needed
> here.  (We dont allow the customers to advertise more specifics i.e.,
> to break the aggregates -- but if you would, prefix-limits could be 
> used here as well, as discussed below where I quote Parantap's note.)
> 
> For peers, however, this is slightly different.  Generating 
> prefix-lists from RIPE DB for our peering sessions would take over 
> 20,000 lines of access lists.  That's simply unacceptable amount of 
> junk to our router configurations.  So, we simply filter based on the 
> AS-numbers, and use the prefix limits (the limit is about 5-10 times 
> as much as they're advertising now) as a means to disconnect the peer 
> if it accidentally starts advertising the whole Internet to us.
> 
> We don't need prefix-limit signalling for this kind of stuff at all, 
> which is why I said in the first place that I fail to see where it's 
> needed but wouldn't object to it being specified as long as it's 
> simple.

Could you please clarify whether (a) you are in favor or against
accepting signalled prefix limit as an IDR WG item, and if yes,
then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
or draft-keyur-prefixlimit-orf-00.txt) would you favor.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA28735 for <[e-mail]>; Tue, 18 May 2004 07:25:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2Wu-0008J6-H0; Tue, 18 May 2004 07:13:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2OC-0005eT-Sx for [e-mail]; Tue, 18 May 2004 07:04:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03455 for <[e-mail]>; Tue, 18 May 2004 07:04:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2O8-00070s-Mb for [e-mail]; Tue, 18 May 2004 07:04:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ2N9-0006bA-00 for [e-mail]; Tue, 18 May 2004 07:03:00 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ2MK-0005nR-00 for [e-mail]; Tue, 18 May 2004 07:02:08 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 394BF2D49E4 for <[e-mail]>; Tue, 18 May 2004 07:01:40 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 80927-02-21 for <[e-mail]>; Tue, 18 May 2004 07:01:27 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E2A682D4847 for <[e-mail]>; Tue, 18 May 2004 07:01:27 -0400 (EDT)
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Thread-Index: AcQ8O5wcHepVs2+xTzqBM6iNGXixkgAiiS6g
From: "Susan Hares" <[e-mail]>
To: "Kurt Erik Lindqvist" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR  autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 07:01:27 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id HAA28735

Kurtis: 

<wg chair hat on> 
All votes are welcomed and answer
the standards question Yakov posed 
earlier. 

Not all votes indicated what will be
deployed in networks or how. 

In our past email discussions, there have
been many threads about making sure each
new feature in bgp is really needed
for operations of networks. 

<wg chair hat off> 

<personal hat on> 
Running code and rough consensus for IETF
usually means these questions are appropriate. 
Yes, I personally care what gets deployed and
that network operators get the tools they need to run 
networks.   I've worked on operator forums
(NANOG, etc) for over 15 years.  
<personal hat off> 

Sue

-----Original Message-----
From: Kurt Erik Lindqvist [mailto:[e-mail]]
Sent: Monday, May 17, 2004 10:38 AM
To: Susan Hares
Cc: Yakov Rekhter; [e-mail]; Enrico Salazar
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Why do you keep asking this? We are here as individuals - right? Or is 
there different value for the votes if you are one or the other?

- - kurtis -

On 2004-05-14, at 17.15, Susan Hares wrote:

> Enrico:
>  
> Thank you for your comments. 
>  Yakov and I appreciate the input.
>  
> Could you let me know if you are:
> a) vendor  b) network operator or
> c) valued researcher/expert
>  or d) other?
>  
> Sue
>  -----Original Message-----
> From: Enrico Salazar [mailto:[e-mail]]
> Sent: Wednesday, May 12, 2004 9:49 PM
> To: Yakov Rekhter; [e-mail]
> Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG 
> document
>
> I object to taking signalled prefix limit, as I think that the 
> existing mechanisms are sufficient to handle real-life scenarios (see
> Pekka's e-mail).
>  
> If there is an agreement that there are real-life scenarios that
> require signalled prefix limit, then I would be in favor of accepting
> draft-keyur-prefixlimit-orf-00.txt.
>  
> I object accepting draft-chavali-bgp-prefixlimit-02.txt.
>  
>    Enrico
>
>
> Yakov Rekhter <[e-mail]> wrote:
> Folks,
>
> Given the current discussion on the mailing list, the deadline
> for comments on accepting draft-chavali-bgp-prefixlimit-02.txt
> as an IDR WG document is extended to May 24, 2004.
>
> This way May 24 is the deadline for comments on the following:
>
> 1. whether to take signalled prefix limit as a WG item
>
> 2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR
> WG document
>
> 3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR
> WG document
>
> In your e-mails please clearly indicate your preferences. Providing
> rationale for your preferences would be extremely useful as well.
>
> Yakov.
>
> P.S If folks feel that the deadline should be extended beyond
> May 24, please say so.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>
> Do you Yahoo!?
> Yahoo! Movies - Buy advance tickets for 'Shrek 2'

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQKjOQqarNKXTPFCVEQIPcACgxp3r6/tDug8mCx9fHij8HDwuTWAAn06X
opfvxAZFuAiCXdYOQr+uEl6E
=IZ/g
-----END PGP SIGNATURE-----


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA27371 for <[e-mail]>; Tue, 18 May 2004 07:12:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2PB-0005ms-KN; Tue, 18 May 2004 07:05:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2B9-00035n-03 for [e-mail]; Tue, 18 May 2004 06:50:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02727 for <[e-mail]>; Tue, 18 May 2004 06:50:29 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2B3-0001M2-Iy for [e-mail]; Tue, 18 May 2004 06:50:29 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ29r-0000up-00 for [e-mail]; Tue, 18 May 2004 06:49:15 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ28x-0000Eh-00 for [e-mail]; Tue, 18 May 2004 06:48:19 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id AB25A2D49E5 for <[e-mail]>; Tue, 18 May 2004 06:47:45 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 80903-03 for <[e-mail]>; Tue, 18 May 2004 06:47:31 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id DB72B2D489E for <[e-mail]>; Tue, 18 May 2004 06:47:31 -0400 (EDT)
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
Thread-Index: AcQ8R4Jr1ITEXw+BQuiwYlFON3QWpwAffZbQ
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>
Cc: "Fang, Luyuan, ALABS" <[e-mail]>, "Ash, Gerald R (Jerry),     ALABS" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 18 May 2004 06:47:31 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id HAA27371

Eric:

Thanks for clarifying that point.

Sue

-----Original Message-----
From: Eric Rosen [mailto:[e-mail]]
Sent: Monday, May 17, 2004 3:45 PM
To: Susan Hares
Cc: Fang, Luyuan, ALABS; Ash, Gerald R (Jerry), ALABS; Yakov Rekhter;
[e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document 



> Could you be specific on what other thresholds? 

In draft-chavali terminology, I think  Luyuan's argument supports the use of
the "maximum prefix limit" but not  the "reset prefix limit" or the "warning
prefix limit". 

Since the  "maximum prefix limit" is  essentially the same (I  think) as the
"prefix limit" of draft-keyur, I don't think that Luyuan's argument provides
a basis for preferring draft-chavali. 


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA22254 for <[e-mail]>; Mon, 17 May 2004 17:55:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPprB-0008KV-HA; Mon, 17 May 2004 17:41:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpVC-0004P4-27 for [e-mail]; Mon, 17 May 2004 17:18:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29656 for <[e-mail]>; Mon, 17 May 2004 17:18:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPpV9-0007BC-NM for [e-mail]; Mon, 17 May 2004 17:18:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPpRJ-00061h-00 for [e-mail]; Mon, 17 May 2004 17:14:26 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BPpN2-0004lQ-00 for [e-mail]; Mon, 17 May 2004 17:10:01 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4HL9X0N001190; Mon, 17 May 2004 17:09:33 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
cc: Curtis Villamizar <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] proposed additional text 
In-reply-to: Your message of "Mon, 17 May 2004 16:28:08 EDT." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 17:09:33 -0400

In message <[e-mail]>, Jeffrey Haas writes:
> Curtis,
> 
> On Mon, May 17, 2004 at 04:12:35PM -0400, Curtis Villamizar wrote:
> > Real threat - very close to zero.  We have better things to worry
> > about.
> 
> I'd agree.  IMO the security folk tend to be very picky about knowing
> the circumstances of where we have issues no matter how small the
> window.
> 
> IIRC, your original objection was showing how this could be done or
> otherwise delete the sentences that covered it.  I think we've
> shown how.  Deriving the unlikelihood of this set of circumstances
> can be left to the reader.
> 
> > Curtis
> 
> -- 
> Jeff Haas 
> NextHop Technologies


The threat is exactly zero if you change the key once a week or more
so I still think the sentence can be omited.  At least it needs to be
clarified.

Curtis

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA22189 for <[e-mail]>; Mon, 17 May 2004 17:54:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpoa-0006YF-Kv; Mon, 17 May 2004 17:38:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpQS-0000em-CA for [e-mail]; Mon, 17 May 2004 17:13:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28742 for <[e-mail]>; Mon, 17 May 2004 17:13:29 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPpQQ-0005sS-4i for [e-mail]; Mon, 17 May 2004 17:13:30 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPpM5-0004a4-00 for [e-mail]; Mon, 17 May 2004 17:09:02 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BPpH9-0003Ey-00 for [e-mail]; Mon, 17 May 2004 17:03:55 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4HL3Q0N001138; Mon, 17 May 2004 17:03:26 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Tony Li <[e-mail]>
cc: [e-mail], "Naidu, Venkata" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] proposed additional text 
In-reply-to: Your message of "Mon, 17 May 2004 13:10:29 PDT." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 17:03:26 -0400

In message <[e-mail]>, Tony Li writes:
> 
> On May 17, 2004, at 12:02 PM, Curtis Villamizar wrote:
> 
> > Like I said this "attack" is a real stretch of the imagination.
> >
> 
> True, but you have to acknowledge that it is possible.  On that basis
> I recommend that we leave the text as is.
> 
> Tony


OK.  If BGP cycles every 8 days and if UPDATE packet size are
distributed over a set of 500 values (for argument sake), then one out
of every 500 cycles on average you'd get the front of the packet to
align.  That's once every 4,000 days, or about 11 years.  Then the
packet size would have to be the same so you have to consider
statistically how often UPDATE packets are the same size (I think we
can agree that spoofing a keepalive is harmless).

So once every few hundred years someone could replay a valid UPDATE
packet and someone out there would be wondering how it is that they
can get to 140.222/16 and a bunch of other places that don't exist and
routes to some places that do exist might be going the wrong way.

That is if no one has changed the MD5 key in that amount of time.
And of course no one will notice that someone is sniffing packets all
this time.

Do we really need to document this as a "threat"?  If so, we should
look more carefully at BGP UPDATE packet size stats and get a more
accurate idea of what the threat is.

And since we know that BGP routing is so incredibly accurate it would
be disasterous if we discovered a BGP session had to be reset every 10
years or 100 years because routes weren't right...  :-)

Of course, since it takes a week or more to cycle through the sequence
numbers changing the MD5 key every couple of days would completely
eliminate the replay threat if anyone thought this threat was real.

Curtis

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA21083 for <[e-mail]>; Mon, 17 May 2004 17:40:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpUt-0004IR-57; Mon, 17 May 2004 17:18:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPom5-0000GJ-9v for [e-mail]; Mon, 17 May 2004 16:31:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23716 for <[e-mail]>; Mon, 17 May 2004 16:31:46 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPom3-0000yI-C8 for [e-mail]; Mon, 17 May 2004 16:31:47 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPokZ-0000HI-00 for [e-mail]; Mon, 17 May 2004 16:30:15 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BPojB-0007EB-00 for [e-mail]; Mon, 17 May 2004 16:28:49 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6EAE12D4827; Mon, 17 May 2004 16:28:19 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 58114-01-48; Mon, 17 May 2004 16:28:08 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 13DB02D489A; Mon, 17 May 2004 16:28:08 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i4HKS8C09020; Mon, 17 May 2004 16:28:08 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: [Idr] proposed additional text
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, May 17, 2004 at 04:12:35PM -0400
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 16:28:08 -0400

Curtis,

On Mon, May 17, 2004 at 04:12:35PM -0400, Curtis Villamizar wrote:
> Real threat - very close to zero.  We have better things to worry
> about.

I'd agree.  IMO the security folk tend to be very picky about knowing
the circumstances of where we have issues no matter how small the
window.

IIRC, your original objection was showing how this could be done or
otherwise delete the sentences that covered it.  I think we've
shown how.  Deriving the unlikelihood of this set of circumstances
can be left to the reader.

> Curtis

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA20875 for <[e-mail]>; Mon, 17 May 2004 17:37:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpTD-00036C-GV; Mon, 17 May 2004 17:16:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoXo-00018y-Nf for [e-mail]; Mon, 17 May 2004 16:17:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22084 for <[e-mail]>; Mon, 17 May 2004 16:17:02 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPoXm-0002lW-Qo for [e-mail]; Mon, 17 May 2004 16:17:02 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPoVW-0001nM-00 for [e-mail]; Mon, 17 May 2004 16:14:42 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BPoTv-00018d-00 for [e-mail]; Mon, 17 May 2004 16:13:03 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4HKCZ0N000909; Mon, 17 May 2004 16:12:35 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
cc: Curtis Villamizar <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] proposed additional text 
In-reply-to: Your message of "Mon, 17 May 2004 14:44:02 EDT." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 16:12:35 -0400

In message <[e-mail]>, Jeffrey Haas writes:
> On Mon, May 17, 2004 at 12:52:05PM -0400, Curtis Villamizar wrote:
> > A replay attack involves sending information later on when it is no
> > longer valid.  Since the TCP sequence number is covered by the TCP
> > checksum, and therefore MD5 digest that replaces it, a replay attack
> > is not possible.  It also covers address and port so you can't read
> > from one connection and replay on another.
> 
> Presume you are in circumstances in which a replay attack is possible.
> Presume also that you can sniff the wire.
> Given the above, the circumstances under which an attack are valid are:
> 1. The key is still the same (or much less likely, a different key
>    results in the same MAC)
> 2. The source, dst, src port, dst port tuples are the same.
> 3. The segment which you are looking to replay is within the window.
> 
> Given all of the above, it is possible to replay the packet.
> If the packet is a SYN or RST, then you can obviously disrupt the session.
> You can gather these by simply sniffing the wire and simply replaying
> any that are within the acceptable TCP session and window.
> 
> If the packet is a data packet, the behavior will depend on the
> TCP implementation.  This may desynchronize the session at the
> least.
> 
> Note that I am not a TCP expert nor do I play one on TV.  However,
> I've heard some interesting stories about how different implementations
> fail to follow the spec and odd behaviors thus caused.
> 
> 
> -- 
> Jeff Haas 
> NextHop Technologies


Unless you can match the exact start and end of the packet after the
wrap occurs, all you have is a DoS attach that is good for one shot
every week or so.  And you have to be able to packet sniff to do it.

Real threat - very close to zero.  We have better things to worry
about.

If some implementation doesn't cease when the BGP flow gets out of
sync its very broken.

Curtis

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA20797 for <[e-mail]>; Mon, 17 May 2004 17:36:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpT4-0002tp-Kp; Mon, 17 May 2004 17:16:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoUn-00005g-Gn for [e-mail]; Mon, 17 May 2004 16:13:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21808 for <[e-mail]>; Mon, 17 May 2004 16:13:55 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPoUl-0001XS-Pk for [e-mail]; Mon, 17 May 2004 16:13:55 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPoTJ-00013r-00 for [e-mail]; Mon, 17 May 2004 16:12:25 -0400
Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1BPoS4-0000GP-00 for [e-mail]; Mon, 17 May 2004 16:11:08 -0400
Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc12) with SMTP id <2004051720103101400f2n2le> (Authid: li.tony); Mon, 17 May 2004 20:10:32 +0000
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: "Naidu, Venkata" <[e-mail]>, [e-mail]
From: Tony Li <[e-mail]>
Subject: Re: [Idr] proposed additional text 
To: [e-mail]
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 13:10:29 -0700

On May 17, 2004, at 12:02 PM, Curtis Villamizar wrote:

> Like I said this "attack" is a real stretch of the imagination.
>

True, but you have to acknowledge that it is possible.  On that basis
I recommend that we leave the text as is.

Tony


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA18962 for <[e-mail]>; Mon, 17 May 2004 17:14:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoIV-00042s-JU; Mon, 17 May 2004 16:01:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPo6U-0007ry-9V for [e-mail]; Mon, 17 May 2004 15:48:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19529 for <[e-mail]>; Mon, 17 May 2004 15:48:48 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPo6S-0007ZY-QD for [e-mail]; Mon, 17 May 2004 15:48:48 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPo5B-00077M-00 for [e-mail]; Mon, 17 May 2004 15:47:30 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BPo3X-0006MJ-00 for [e-mail]; Mon, 17 May 2004 15:45:47 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 May 2004 12:45:22 -0700
X-BrightmailFiltered: true
Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4HJjDpI006682; Mon, 17 May 2004 15:45:13 -0400 (EDT)
Message-Id: <[e-mail]>
To: "Susan Hares" <[e-mail]>
cc: "Fang, Luyuan, ALABS" <[e-mail]>, "Ash, Gerald R (Jerry), ALABS" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
In-reply-to: Your message of Mon, 17 May 2004 13:57:29 -0400. <[e-mail]> 
Reply-To: [e-mail]
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
From: Eric Rosen <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 15:45:15 -0400

> Could you be specific on what other thresholds? 

In draft-chavali terminology, I think  Luyuan's argument supports the use of
the "maximum prefix limit" but not  the "reset prefix limit" or the "warning
prefix limit". 

Since the  "maximum prefix limit" is  essentially the same (I  think) as the
"prefix limit" of draft-keyur, I don't think that Luyuan's argument provides
a basis for preferring draft-chavali. 


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA12303 for <[e-mail]>; Mon, 17 May 2004 15:46:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnbm-0006KU-K2; Mon, 17 May 2004 15:17:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnSQ-0007zs-Qw for [e-mail]; Mon, 17 May 2004 15:07:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15479 for <[e-mail]>; Mon, 17 May 2004 15:07:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPnSN-0000Ui-Rr for [e-mail]; Mon, 17 May 2004 15:07:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnRX-0000AT-00 for [e-mail]; Mon, 17 May 2004 15:06:32 -0400
Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1BPnQr-0007Zd-00 for [e-mail]; Mon, 17 May 2004 15:05:49 -0400
Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc11) with SMTP id <20040517190518013000q4h2e> (Authid: li.tony); Mon, 17 May 2004 19:05:19 +0000
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
From: Tony Li <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
To: Yakov Rekhter <[e-mail]>
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 12:05:18 -0700

Yakov,

I am against accepting signalled prefix limits as an IDR WG item.

Tony


On May 17, 2004, at 11:22 AM, Yakov Rekhter wrote:

> Tony,
>
> Could you please clarify whether (a) you are in favor or against
> accepting signalled prefix limit as an IDR WG item, and if yes,
> then (b) which of the two approaches 
> (draft-chavali-bgp-prefixlimit-02.txt
> or draft-keyur-prefixlimit-orf-00.txt) would you favor.
>
> Yakov.
>


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA12210 for <[e-mail]>; Mon, 17 May 2004 15:45:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnbi-0006Io-BA; Mon, 17 May 2004 15:17:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnQL-000413-UV for [e-mail]; Mon, 17 May 2004 15:05:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15178 for <[e-mail]>; Mon, 17 May 2004 15:05:14 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPnQI-0007Z3-Vq for [e-mail]; Mon, 17 May 2004 15:05:15 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnPJ-0007Cs-00 for [e-mail]; Mon, 17 May 2004 15:04:13 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BPnOK-0006ru-00 for [e-mail]; Mon, 17 May 2004 15:03:12 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4HJ2f0N000587; Mon, 17 May 2004 15:02:41 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Naidu, Venkata" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] proposed additional text 
In-reply-to: Your message of "Mon, 17 May 2004 13:59:50 EDT." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 15:02:41 -0400

In message <[e-mail]>, 
"Naidu, Venkata" writes:
> Curtis,
> 
> -> A replay attack involves sending information later on when it is no
> -> longer valid.  Since the TCP sequence number is covered by the TCP
> -> checksum, and therefore MD5 digest that replaces it, a replay attack
> -> is not possible.  
> 
>   IMHO, TCP sequence number is not designed to protect replay attacks,
>   rather the intention is to detect network errors/congestion and to 
>   provide a form of simple ordered byte stream reliability.
> 
>   For example, I computed that, the sequence number would wrap around:
>   in (2^32 bytes * 8 bits/byte) / (10 * 10^6 bit/sec) = 3435.6 sec ~ 
>   1 hour using 32 bit sequence number when streaming 10 Mbps, 
>   in 343.56 sec using 32 bit sequence number when streaming 100Mbps, 
>   in 0.00046 sec using 32 bit sequence numbers when streaming 75Tbps.
>   
>   I am not sure how TCP checksum and MD5 digest is going to protect
>   if the attacker is not going to change a single bit the segment.
> 
>   So, all the replay attacker has to do is to wait for the next 
>   window to sneak in the old segment after sequence number wrapping.
>   This is the main reason why IPSec argued to increase the sequence
>   number from 32 bit to 64 bits.
> 
> Venkata.


BGP does not stream continuously at 10 mb/s.  More like 10s of kb/s on
averge, usually less.  That would be an the order of 700,000 seconds
at about 50 kb/s.

So at best after about 8 days a denial of service would be possible.
Keep in mind that the old sequence of bytes has to fit exactly into a
packet in the new sequence of bytes - same start byte for the packet
and same length.  Otherwise the BGP session does a cease and there is
no damage except a temporary DoS.  Not also that the ACK sequence
number is part of the MD5.

Like I said this "attack" is a real stretch of the imagination.

For general IPSEC use it matters because inserting '\n rm -rf / \n'
(or equivalent depending on OS) into a telnet stream at almost any
time would be a bad thing.  For BGP a cease would occur and the damage
is limited to a DoS.

Curtis

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09508 for <[e-mail]>; Mon, 17 May 2004 15:14:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnDk-0005Ku-EL; Mon, 17 May 2004 14:52:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPn8k-00046V-R8 for [e-mail]; Mon, 17 May 2004 14:47:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13901 for <[e-mail]>; Mon, 17 May 2004 14:47:04 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPn8i-0000tk-2s for [e-mail]; Mon, 17 May 2004 14:47:04 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPn7c-0000Ry-00 for [e-mail]; Mon, 17 May 2004 14:45:56 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BPn6R-0007XP-00 for [e-mail]; Mon, 17 May 2004 14:44:43 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7E2822D49C9; Mon, 17 May 2004 14:44:13 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 54699-01-47; Mon, 17 May 2004 14:44:02 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 306252D49CB; Mon, 17 May 2004 14:44:02 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i4HIi2207945; Mon, 17 May 2004 14:44:02 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: [Idr] proposed additional text
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, May 17, 2004 at 12:52:05PM -0400
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 14:44:02 -0400

On Mon, May 17, 2004 at 12:52:05PM -0400, Curtis Villamizar wrote:
> A replay attack involves sending information later on when it is no
> longer valid.  Since the TCP sequence number is covered by the TCP
> checksum, and therefore MD5 digest that replaces it, a replay attack
> is not possible.  It also covers address and port so you can't read
> from one connection and replay on another.

Presume you are in circumstances in which a replay attack is possible.
Presume also that you can sniff the wire.
Given the above, the circumstances under which an attack are valid are:
1. The key is still the same (or much less likely, a different key
   results in the same MAC)
2. The source, dst, src port, dst port tuples are the same.
3. The segment which you are looking to replay is within the window.

Given all of the above, it is possible to replay the packet.
If the packet is a SYN or RST, then you can obviously disrupt the session.
You can gather these by simply sniffing the wire and simply replaying
any that are within the acceptable TCP session and window.

If the packet is a data packet, the behavior will depend on the
TCP implementation.  This may desynchronize the session at the
least.

Note that I am not a TCP expert nor do I play one on TV.  However,
I've heard some interesting stories about how different implementations
fail to follow the spec and odd behaviors thus caused.


-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA08884 for <[e-mail]>; Mon, 17 May 2004 15:06:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnDd-0005Iy-6u; Mon, 17 May 2004 14:52:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPn7p-0003yv-5U for [e-mail]; Mon, 17 May 2004 14:46:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13763 for <[e-mail]>; Mon, 17 May 2004 14:46:06 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPn7m-0000WR-EI for [e-mail]; Mon, 17 May 2004 14:46:06 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPn6e-000013-00 for [e-mail]; Mon, 17 May 2004 14:44:56 -0400
Received: from m018e36d0.tmodns.net ([208.54.142.1] helo=proradius03) by ietf-mx with esmtp (Exim 4.12) id 1BPn5R-00075g-00 for [e-mail]; Mon, 17 May 2004 14:43:41 -0400
Received: from laptop2.kurtis.pp.se ([10.242.8.212]) by proradius03 (8.11.6+Sun/8.11.6) with ESMTP id i4HIRfo27353 for <[e-mail]>; Mon, 17 May 2004 11:27:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 6038C402168; Mon, 17 May 2004 20:10:01 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=ISO-8859-1; format=fixed
Message-Id: <[e-mail]>
Cc: "Yakov Rekhter" <[e-mail]>, <[e-mail]>, "Enrico Salazar" <[e-mail]>
From: Kurt Erik Lindqvist <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
To: "Susan Hares" <[e-mail]>
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,DATE_IN_PAST_03_06, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 16:37:51 +0200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA08884

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Why do you keep asking this? We are here as individuals - right? Or is 
there different value for the votes if you are one or the other?

- - kurtis -

On 2004-05-14, at 17.15, Susan Hares wrote:

> Enrico:
>  
> Thank you for your comments. 
>  Yakov and I appreciate the input.
>  
> Could you let me know if you are:
> a) vendor  b) network operator or
> c) valued researcher/expert
>  or d) other?
>  
> Sue
>  -----Original Message-----
> From: Enrico Salazar [mailto:[e-mail]]
> Sent: Wednesday, May 12, 2004 9:49 PM
> To: Yakov Rekhter; [e-mail]
> Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG 
> document
>
> I object to taking signalled prefix limit, as I think that the 
> existing mechanisms are sufficient to handle real-life scenarios (see
> Pekka's e-mail).
>  
> If there is an agreement that there are real-life scenarios that
> require signalled prefix limit, then I would be in favor of accepting
> draft-keyur-prefixlimit-orf-00.txt.
>  
> I object accepting draft-chavali-bgp-prefixlimit-02.txt.
>  
>    Enrico
>
>
> Yakov Rekhter <[e-mail]> wrote:
> Folks,
>
> Given the current discussion on the mailing list, the deadline
> for comments on accepting draft-chavali-bgp-prefixlimit-02.txt
> as an IDR WG document is extended to May 24, 2004.
>
> This way May 24 is the deadline for comments on the following:
>
> 1. whether to take signalled prefix limit as a WG item
>
> 2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR
> WG document
>
> 3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR
> WG document
>
> In your e-mails please clearly indicate your preferences. Providing
> rationale for your preferences would be extremely useful as well.
>
> Yakov.
>
> P.S If folks feel that the deadline should be extended beyond
> May 24, please say so.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>
> Do you Yahoo!?
> Yahoo! Movies - Buy advance tickets for 'Shrek 2'

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQKjOQqarNKXTPFCVEQIPcACgxp3r6/tDug8mCx9fHij8HDwuTWAAn06X
opfvxAZFuAiCXdYOQr+uEl6E
=IZ/g
-----END PGP SIGNATURE-----


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA06936 for <[e-mail]>; Mon, 17 May 2004 14:43:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmy3-0001hW-Cd; Mon, 17 May 2004 14:36:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmpE-0008HL-Sk for [e-mail]; Mon, 17 May 2004 14:26:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11352 for <[e-mail]>; Mon, 17 May 2004 14:26:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPmpC-0000n0-8k for [e-mail]; Mon, 17 May 2004 14:26:54 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPmn9-0000DX-00 for [e-mail]; Mon, 17 May 2004 14:24:48 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BPmlb-0007GE-00 for [e-mail]; Mon, 17 May 2004 14:23:11 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4HIMeBm017018; Mon, 17 May 2004 11:22:40 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4HIMeJ98492; Mon, 17 May 2004 11:22:40 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Tony Li <[e-mail]>
cc: [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
In-Reply-To: Your message of "Fri, 14 May 2004 15:15:37 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 11:22:40 -0700

Tony,

Could you please clarify whether (a) you are in favor or against
accepting signalled prefix limit as an IDR WG item, and if yes,
then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
or draft-keyur-prefixlimit-orf-00.txt) would you favor.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA05101 for <[e-mail]>; Mon, 17 May 2004 14:20:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmZz-00063h-Jf; Mon, 17 May 2004 14:11:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmRH-0003Mc-Uu for [e-mail]; Mon, 17 May 2004 14:02:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08949 for <[e-mail]>; Mon, 17 May 2004 14:02:09 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPmRF-0007bd-J0 for [e-mail]; Mon, 17 May 2004 14:02:09 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPmQN-0007IF-00 for [e-mail]; Mon, 17 May 2004 14:01:15 -0400
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1BPmPl-0006qj-00 for [e-mail]; Mon, 17 May 2004 14:00:37 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i4HHxvQG017738; Mon, 17 May 2004 13:59:57 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05498; Mon, 17 May 2004 13:59:57 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <J6HTAWKH>; Mon, 17 May 2004 13:59:56 -0400
Message-ID: <[e-mail]>
From: "Naidu, Venkata" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: [Idr] proposed additional text 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 13:59:50 -0400

Curtis,

-> A replay attack involves sending information later on when it is no
-> longer valid.  Since the TCP sequence number is covered by the TCP
-> checksum, and therefore MD5 digest that replaces it, a replay attack
-> is not possible.  

  IMHO, TCP sequence number is not designed to protect replay attacks,
  rather the intention is to detect network errors/congestion and to 
  provide a form of simple ordered byte stream reliability.

  For example, I computed that, the sequence number would wrap around:
  in (2^32 bytes * 8 bits/byte) / (10 * 10^6 bit/sec) = 3435.6 sec ~ 
  1 hour using 32 bit sequence number when streaming 10 Mbps, 
  in 343.56 sec using 32 bit sequence number when streaming 100Mbps, 
  in 0.00046 sec using 32 bit sequence numbers when streaming 75Tbps.
  
  I am not sure how TCP checksum and MD5 digest is going to protect
  if the attacker is not going to change a single bit the segment.

  So, all the replay attacker has to do is to wait for the next 
  window to sneak in the old segment after sequence number wrapping.
  This is the main reason why IPSec argued to increase the sequence
  number from 32 bit to 64 bits.

Venkata.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04840 for <[e-mail]>; Mon, 17 May 2004 14:16:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmZw-00063B-N2; Mon, 17 May 2004 14:11:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmPN-0003D4-P0 for [e-mail]; Mon, 17 May 2004 14:00:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08828 for <[e-mail]>; Mon, 17 May 2004 14:00:11 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPmPL-0006wi-AT for [e-mail]; Mon, 17 May 2004 14:00:11 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPmOM-0006bp-00 for [e-mail]; Mon, 17 May 2004 13:59:11 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BPmNR-0005zZ-00 for [e-mail]; Mon, 17 May 2004 13:58:13 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9FBEF2D49C7 for <[e-mail]>; Mon, 17 May 2004 13:57:43 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 52405-01-88 for <[e-mail]>; Mon, 17 May 2004 13:57:29 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9E2B52D49B1 for <[e-mail]>; Mon, 17 May 2004 13:57:29 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
Thread-Index: AcQ8M4R1yuHFYUSIQWuHPDiteEiyQAAAbryg
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>, "Fang, Luyuan, ALABS" <[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 13:57:29 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA04840

Eric:

Could you clarify for me a few things in
your last paragraph

"I don't see the argument  for dynamically learning multiple threshold levels
from a peer.  Especially as there  are no real semantics associated with the
other thresholds. "

Could you be specific on what other thresholds?

Sue

-----Original Message-----
From: Eric Rosen [mailto:[e-mail]]
Sent: Monday, May 17, 2004 1:01 PM
To: Fang, Luyuan, ALABS
Cc: Ash, Gerald R (Jerry), ALABS; Yakov Rekhter; [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document 



> In the current implementation, the  prefix limit is only configured on the
> BGP receiver (e.g., provider edge router), the BGP speaker (e.g. CPE) does
> not  have   any  control.   Some  implementation  has   warning  threshold
> option. When warning  limit is reached, the trap will only  show up on the
> provider  side, the  operator  has to  contact  the customer  by phone  or
> through some messaging systems.  

This suggests that it is useful for  a BGP speaker to know that a given peer
will only be  able to receive n prefixes.  In that  case, it certainly makes
sense for  the value  n to be  learned dynamically.   Both of the  drafts in
question support that functionality. 

I don't see the argument  for dynamically learning multiple threshold levels
from a peer.  Especially as there  are no real semantics associated with the
other thresholds. 


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

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00484 for <[e-mail]>; Mon, 17 May 2004 13:24:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlbo-0004gc-R7; Mon, 17 May 2004 13:09:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlWO-0003GC-7N for [e-mail]; Mon, 17 May 2004 13:03:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05297 for <[e-mail]>; Mon, 17 May 2004 13:03:20 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPlWM-0002nS-ES for [e-mail]; Mon, 17 May 2004 13:03:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlVM-0002Qo-00 for [e-mail]; Mon, 17 May 2004 13:02:20 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BPlUP-0001kL-00 for [e-mail]; Mon, 17 May 2004 13:01:21 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 17 May 2004 10:03:50 -0700
X-BrightmailFiltered: true
Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4HG0mpI018155; Mon, 17 May 2004 12:00:49 -0400 (EDT)
Message-Id: <[e-mail]>
To: "Fang, Luyuan, ALABS" <[e-mail]>
cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 
In-reply-to: Your message of Fri, 14 May 2004 13:56:41 -0500. <[e-mail]> 
Reply-To: [e-mail]
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
From: Eric Rosen <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 13:00:48 -0400

> In the current implementation, the  prefix limit is only configured on the
> BGP receiver (e.g., provider edge router), the BGP speaker (e.g. CPE) does
> not  have   any  control.   Some  implementation  has   warning  threshold
> option. When warning  limit is reached, the trap will only  show up on the
> provider  side, the  operator  has to  contact  the customer  by phone  or
> through some messaging systems.  

This suggests that it is useful for  a BGP speaker to know that a given peer
will only be  able to receive n prefixes.  In that  case, it certainly makes
sense for  the value  n to be  learned dynamically.   Both of the  drafts in
question support that functionality. 

I don't see the argument  for dynamically learning multiple threshold levels
from a peer.  Especially as there  are no real semantics associated with the
other thresholds. 


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00086 for <[e-mail]>; Mon, 17 May 2004 13:19:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlaw-0004Pw-QP; Mon, 17 May 2004 13:08:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlNq-00022T-BX for [e-mail]; Mon, 17 May 2004 12:54:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04789 for <[e-mail]>; Mon, 17 May 2004 12:54:31 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPlNo-0007VU-Nq for [e-mail]; Mon, 17 May 2004 12:54:32 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlMq-00079q-00 for [e-mail]; Mon, 17 May 2004 12:53:33 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BPlME-0006o6-00 for [e-mail]; Mon, 17 May 2004 12:52:54 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4HGq5aL072432; Mon, 17 May 2004 12:52:05 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] proposed additional text 
In-reply-to: Your message of "Mon, 17 May 2004 06:44:56 PDT." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 12:52:05 -0400

In message <[e-mail]>, Yakov Rekhter writes
:
> Folks,
> 
> During the IESG review Steve Kent proposed the following text to
> be added to the BGP protocol spec. 
> 
>    BGP makes use of TCP for reliable transport of its traffic between
>    peer routers. To provide connection-oriented integrity and data
>    origin authentication, on a point-to-point basis, BGP specifies
>    use of the mechanism defined in RFC 2385. These services are intended
>    to detect and reject active wiretapping attacks against the
>    inter-router TCP connections. Absent use of mechanisms that effect
>    these security services, attackers can disrupt these TCP connections
>    and/or masquerade as a legitimate peer router. Because the mechanism
>    defined in the RFC does not provide peer-entity authentication,
>    these connections are still subject to some forms of replay attacks.
>    
>    The mechanism defined in RFC 2385 augments the normal TCP checksum
>    with a 16-byte message authentication code (MAC) that is computed
>    over the same data as the TCP checksum. This MAC is based on a
>    one-way hash function (MD5) and use of a secret key. The key is
>    shared between peer routers and is used to generate MAC values that
>    are not readily computed by an attacker who does not have access
>    to the key. A compliant implementation must support this mechanism,
>    and must allow a network administrator to activate it on a per-peer
>    basis.
>    
>    RFC 2385 does not specify a means of managing (e.g., generating
>    and distributing) the keys used to compute the MAC. A different
>    key should be used for each protected peer. If the same key is used
>    for multiple peers, the offered security services are degraded.
>    (In fact, the reuse of the same key with the same peer for multiple
>    TCP connections already represents a vulnerability, as noted above.)
>    Obviously, each  key also should be chosen so as to be hard for an
>    attacker to guess.  The techniques specified in RFC 1750 for random
>    number generation provide a guide for generation of values that
>    could be used as keys. Keys also should be changed periodically,
>    to minimize the impact of a key compromise or successful cryptanalytic
>    attack.
>    
>    RFC 2385 calls for implementations to support keys "composed of a
>    string of printable ASCII of 80 bytes or less ."  While it is
>    difficult to specify an appropriate key size for a wide range of
>    environments, it is worth noting that current standards for analogous
>    integrity algorithms make use of key sizes of about 128-256 bits.
>    An 80-byte, printable ASCII string, falls into this range.
> 
> If there are any objections to adding this text to the protocol
> spec please post them to the list by May 24, 2004.
> 
> Yakov.


Yakov,

This is a stretch.  Regardless, I suggest we include this exactly as
Steve suggested unless any part of it can be shown to be false.

>    Because the mechanism
>    defined in the RFC does not provide peer-entity authentication,
>    these connections are still subject to some forms of replay
>    attacks.

A replay attack involves sending information later on when it is no
longer valid.  Since the TCP sequence number is covered by the TCP
checksum, and therefore MD5 digest that replaces it, a replay attack
is not possible.  It also covers address and port so you can't read
from one connection and replay on another.

If Steve means that a DoS is possible by sending the same valid packet
over and over, even though TCP will ignore the resend of data prior to
the sequence number, then the above statement should either be dropped
or changed to state that a DoS attack is possible which does no damage
other than increase CPU loading.

Unless Steve can tell us how a replay attack is possible, then this
sentence should be removed.  If it is a false statement, it needs to
be removed.

Curtis

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28586 for <[e-mail]>; Mon, 17 May 2004 13:01:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlGZ-0001LV-VD; Mon, 17 May 2004 12:47:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPl34-0006rv-JK for [e-mail]; Mon, 17 May 2004 12:33:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03420 for <[e-mail]>; Mon, 17 May 2004 12:33:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPl32-00007r-Qw for [e-mail]; Mon, 17 May 2004 12:33:04 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPl25-0007aF-00 for [e-mail]; Mon, 17 May 2004 12:32:06 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BPl0w-0006tt-00 for [e-mail]; Mon, 17 May 2004 12:30:55 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4HGUN949490 for <[e-mail]>; Mon, 17 May 2004 09:30:23 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4HGUIJ81897 for <[e-mail]>; Mon, 17 May 2004 09:30:18 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] draft-ietf-idr-rfc2796bis-01.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 09:30:18 -0700

Folks,

draft-ietf-idr-rfc2796bis-01.txt reflects the comments received
during the WG Last Call.

Yakov.
------- Forwarded Message

Date:    Thu, 13 May 2004 13:02:03 -0400
From:    [e-mail]
To:      [e-mail]
cc:      [e-mail]
Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-01.txt

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF
.

	Title		: BGP Route Reflection - An Alternative to Full Mesh IB
GP
	Author(s)	: T. Bates, et al. 
	Filename	: draft-ietf-idr-rfc2796bis-01.txt
	Pages		: 12
	Date		: 2004-5-12
	
The Border Gateway Protocol (BGP) is an inter-autonomous system
   routing protocol designed for TCP/IP internets. Typically all BGP
   speakers within a single AS must be fully meshed so that any external
   routing information must be re-distributed to all other routers
   within that AS. This represents a serious scaling problem that has
   been well documented with several alternatives proposed.

   This document describes the use and design of a method known as
   "Route Reflection" to alleviate the the need for "full mesh" IBGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the mess
age.  
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-ietf-idr-rfc2796bis-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-rfc2796bis-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.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-rfc2796bis-01.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-rfc2796bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

- --OtherAccess--

- --NextPart--



_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce

------- End of Forwarded Message


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA23135 for <[e-mail]>; Mon, 17 May 2004 11:49:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkCm-0005Tj-62; Mon, 17 May 2004 11:39:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPk2N-0003c8-Q8 for [e-mail]; Mon, 17 May 2004 11:28:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28325 for <[e-mail]>; Mon, 17 May 2004 11:28:17 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPk2M-0000Wc-Rx for [e-mail]; Mon, 17 May 2004 11:28:18 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPk1M-0000CV-00 for [e-mail]; Mon, 17 May 2004 11:27:17 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BPk0l-0007e0-00 for [e-mail]; Mon, 17 May 2004 11:26:39 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 May 2004 07:33:12 +0000
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4HFQ5W9023867; Mon, 17 May 2004 08:26:06 -0700 (PDT)
Received: from [192.168.42.3] (dhcp-64-101-214-222.cisco.com [64.101.214.222]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA24340; Mon, 17 May 2004 11:26:05 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p06020492bcce88c75148@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Idr] proposed additional text
Cc: [e-mail], Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 11:26:41 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA23135

At 6:44 AM -0700 5/17/04, Yakov Rekhter wrote:
>Folks,
>
>During the IESG review Steve Kent proposed the following text to
>be added to the BGP protocol spec.
>
>    BGP makes use of TCP for reliable transport of its traffic between
>    peer routers. To provide connection-oriented integrity and data
>    origin authentication, on a point-to-point basis, BGP specifies
>    use of the mechanism defined in RFC 2385. These services are intended
>    to detect and reject active wiretapping attacks against the
>    inter-router TCP connections. Absent use of mechanisms that effect
>    these security services, attackers can disrupt these TCP connections
>    and/or masquerade as a legitimate peer router. Because the mechanism
>    defined in the RFC does not provide peer-entity authentication,
>    these connections are still subject to some forms of replay attacks.
>   
>    The mechanism defined in RFC 2385 augments the normal TCP checksum
>    with a 16-byte message authentication code (MAC) that is computed
>    over the same data as the TCP checksum. This MAC is based on a
>    one-way hash function (MD5) and use of a secret key. The key is
>    shared between peer routers and is used to generate MAC values that
>    are not readily computed by an attacker who does not have access
>    to the key. A compliant implementation must support this mechanism,
>    and must allow a network administrator to activate it on a per-peer
>    basis.
>   
>    RFC 2385 does not specify a means of managing (e.g., generating
>    and distributing) the keys used to compute the MAC. A different
>    key should be used for each protected peer. If the same key is used
>    for multiple peers, the offered security services are degraded.

I assume this refers to the increased probability 
of the key being operationally compromised. 
Perhaps this should be made explicit.

>    (In fact, the reuse of the same key with the same peer for multiple
>    TCP connections already represents a vulnerability, as noted above.)

The parenthetical comment has an unresolved 
reference -- the "noted above" ain't above. 
(Unless this relates to something already in the 
spec and not the proposed text?)

>    Obviously, each  key also should be chosen so as to be hard for an
>    attacker to guess.  The techniques specified in RFC 1750 for random
>    number generation provide a guide for generation of values that
>    could be used as keys. Keys also should be changed periodically,
>    to minimize the impact of a key compromise or successful cryptanalytic
>    attack.
>   
>    RFC 2385 calls for implementations to support keys "composed of a
>    string of printable ASCII of 80 bytes or less ."  While it is
>    difficult to specify an appropriate key size for a wide range of
>    environments, it is worth noting that current standards for analogous
>    integrity algorithms make use of key sizes of about 128-256 bits.
>    An 80-byte, printable ASCII string, falls into this range.
>
>If there are any objections to adding this text to the protocol
>spec please post them to the list by May 24, 2004.

--John

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20466 for <[e-mail]>; Mon, 17 May 2004 11:11:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPjer-0000gW-Ci; Mon, 17 May 2004 11:04:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPjaD-0000EK-1r for [e-mail]; Mon, 17 May 2004 10:59:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27004 for <[e-mail]>; Mon, 17 May 2004 10:59:09 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPjaA-0006Vq-5a for [e-mail]; Mon, 17 May 2004 10:59:10 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPjZ4-00069W-00 for [e-mail]; Mon, 17 May 2004 10:58:02 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BPjYH-0005Is-00 for [e-mail]; Mon, 17 May 2004 10:57:13 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4HEugBm016187; Mon, 17 May 2004 07:56:42 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4HEugJ70444; Mon, 17 May 2004 07:56:42 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
cc: [e-mail]
Subject: Re: [Idr] proposed additional text 
In-Reply-To: Your message of "Mon, 17 May 2004 10:43:19 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 07:56:42 -0700

Jeff,

> Yakov,
> 
> On Mon, May 17, 2004 at 06:44:56AM -0700, Yakov Rekhter wrote:
> > During the IESG review Steve Kent proposed the following text to
> > be added to the BGP protocol spec. 
> 
> Where will this text be inserted into the BGP specification?

Perhaps in the Security Considerations section.

> We don't usually speak of routers, we speak of BGP speakers and
> probably should use that consistently throughout this text.

Sure.

> >    inter-router TCP connections. Absent use of mechanisms that effect
> >    these security services, attackers can disrupt these TCP connections
> >    and/or masquerade as a legitimate peer router. Because the mechanism
> 
> s/Absent use of mechanisms.*,/In the absence of these security mechanisms/
> or something similar?

Sure.

> >    to the key. A compliant implementation must support this mechanism,
> >    and must allow a network administrator to activate it on a per-peer
> 
> s/must/MUST/g

Sure.

> >    could be used as keys. Keys also should be changed periodically,
> 
> Should "should" be "SHOULD"? :-)

Sure.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA19141 for <[e-mail]>; Mon, 17 May 2004 10:52:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPjQQ-0007WO-7m; Mon, 17 May 2004 10:49:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPjNT-00070y-W7 for [e-mail]; Mon, 17 May 2004 10:46:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26246 for <[e-mail]>; Mon, 17 May 2004 10:46:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPjNR-000232-HG for [e-mail]; Mon, 17 May 2004 10:46:01 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPjMS-0001iq-00 for [e-mail]; Mon, 17 May 2004 10:45:00 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BPjLV-00016T-00 for [e-mail]; Mon, 17 May 2004 10:44:01 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B65162D49AD; Mon, 17 May 2004 10:43:30 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 47773-01-10; Mon, 17 May 2004 10:43:19 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6CF8C2D487D; Mon, 17 May 2004 10:43:19 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i4HEhJ207093; Mon, 17 May 2004 10:43:19 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] proposed additional text
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, May 17, 2004 at 06:44:56AM -0700
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 10:43:19 -0400

Yakov,

On Mon, May 17, 2004 at 06:44:56AM -0700, Yakov Rekhter wrote:
> During the IESG review Steve Kent proposed the following text to
> be added to the BGP protocol spec. 

Where will this text be inserted into the BGP specification?

We don't usually speak of routers, we speak of BGP speakers and
probably should use that consistently throughout this text.

>    inter-router TCP connections. Absent use of mechanisms that effect
>    these security services, attackers can disrupt these TCP connections
>    and/or masquerade as a legitimate peer router. Because the mechanism

s/Absent use of mechanisms.*,/In the absence of these security mechanisms/

or something similar?

>    to the key. A compliant implementation must support this mechanism,
>    and must allow a network administrator to activate it on a per-peer

s/must/MUST/g

>    could be used as keys. Keys also should be changed periodically,

Should "should" be "SHOULD"? :-)

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA14538 for <[e-mail]>; Mon, 17 May 2004 09:51:57 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPiUJ-0007hw-7P; Mon, 17 May 2004 09:49:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPiSf-0007TD-O6 for [e-mail]; Mon, 17 May 2004 09:47:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22206 for <[e-mail]>; Mon, 17 May 2004 09:47:19 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPiSd-00068k-GU for [e-mail]; Mon, 17 May 2004 09:47:19 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPiRs-0005oC-00 for [e-mail]; Mon, 17 May 2004 09:46:33 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BPiQo-0005QL-00 for [e-mail]; Mon, 17 May 2004 09:45:26 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4HDiuBm013250 for <[e-mail]>; Mon, 17 May 2004 06:44:56 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4HDiuJ54067 for <[e-mail]>; Mon, 17 May 2004 06:44:56 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] proposed additional text
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 17 May 2004 06:44:56 -0700

Folks,

During the IESG review Steve Kent proposed the following text to
be added to the BGP protocol spec. 

   BGP makes use of TCP for reliable transport of its traffic between
   peer routers. To provide connection-oriented integrity and data
   origin authentication, on a point-to-point basis, BGP specifies
   use of the mechanism defined in RFC 2385. These services are intended
   to detect and reject active wiretapping attacks against the
   inter-router TCP connections. Absent use of mechanisms that effect
   these security services, attackers can disrupt these TCP connections
   and/or masquerade as a legitimate peer router. Because the mechanism
   defined in the RFC does not provide peer-entity authentication,
   these connections are still subject to some forms of replay attacks.
   
   The mechanism defined in RFC 2385 augments the normal TCP checksum
   with a 16-byte message authentication code (MAC) that is computed
   over the same data as the TCP checksum. This MAC is based on a
   one-way hash function (MD5) and use of a secret key. The key is
   shared between peer routers and is used to generate MAC values that
   are not readily computed by an attacker who does not have access
   to the key. A compliant implementation must support this mechanism,
   and must allow a network administrator to activate it on a per-peer
   basis.
   
   RFC 2385 does not specify a means of managing (e.g., generating
   and distributing) the keys used to compute the MAC. A different
   key should be used for each protected peer. If the same key is used
   for multiple peers, the offered security services are degraded.
   (In fact, the reuse of the same key with the same peer for multiple
   TCP connections already represents a vulnerability, as noted above.)
   Obviously, each  key also should be chosen so as to be hard for an
   attacker to guess.  The techniques specified in RFC 1750 for random
   number generation provide a guide for generation of values that
   could be used as keys. Keys also should be changed periodically,
   to minimize the impact of a key compromise or successful cryptanalytic
   attack.
   
   RFC 2385 calls for implementations to support keys "composed of a
   string of printable ASCII of 80 bytes or less ."  While it is
   difficult to specify an appropriate key size for a wide range of
   environments, it is worth noting that current standards for analogous
   integrity algorithms make use of key sizes of about 128-256 bits.
   An 80-byte, printable ASCII string, falls into this range.

If there are any objections to adding this text to the protocol
spec please post them to the list by May 24, 2004.

Yakov.

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA10133 for <[e-mail]>; Fri, 14 May 2004 19:22:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOlrb-0007c9-71; Fri, 14 May 2004 19:13:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOlVe-0003VG-Ce for [e-mail]; Fri, 14 May 2004 18:50:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04636 for <[e-mail]>; Fri, 14 May 2004 18:50:25 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOlVb-0005p5-7Q for [e-mail]; Fri, 14 May 2004 18:50:27 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOlUn-0005Lh-00 for [e-mail]; Fri, 14 May 2004 18:49:38 -0400
Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1BOlU4-0004oq-00 for [e-mail]; Fri, 14 May 2004 18:48:52 -0400
Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc11) with SMTP id <2004051422482201300t97sve> (Authid: li.tony); Fri, 14 May 2004 22:48:22 +0000
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, <[e-mail]>
From: Tony Li <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
To: "Fang, Luyuan, ALABS" <[e-mail]>
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 14 May 2004 15:48:21 -0700

I agree.  We should make boxes better.  And when we realize that we've 
made a mistake, then
we should turn around and fix it.  Not patch up the hole in the side of 
the ship and keep
on sailing as if we didn't just hit a reef.

Tony


On May 14, 2004, at 3:25 PM, Fang, Luyuan, ALABS wrote:

> I do not want to go into the discussion of BGP should be used for 2547 
> or not. It is beyond this subject. But I want to say that something 
> has to be used if we want to provide 2547 kind of network based VPN, 
> whether it is BGP, or other existing protocols or create some new 
> protocols, there is no free lunch. Perfect or not, 2547 VPN services 
> are highly on demand by customers, and good revenue sources for 
> providers. The fact is that it is there, in most provider networks 
> worldwide.
>
> If we only want to stay where we were as many years ago, there were 
> many things we did not need to worry about...
>
> The prefix limit needs largely come from box scaling issues. I'd think 
> focusing on getting the routers more powerful, efficient, and capable 
> would be rather helpful. It is providers' job to provide as many 
> enhanced services as possible to their customers, it is vendors' job 
> to make boxes better each year. Customers, providers, and vendors all 
> benefit from the continues evolution/improvement, right?
>
> Luyuan
>
>
>
> -----Original Message-----
> From: Tony Li [mailto:[e-mail]]
> Sent: Friday, May 14, 2004 5:09 PM
> To: Fang, Luyuan, ALABS
> Cc: Ash, Gerald R (Jerry), ALABS; Yakov Rekhter; [e-mail]
> Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
> document
>
>
>
> Isn't this just a band-aid to cover up the fundamental architectural
> flaw of mis-using
> BGP for 2547?  If the CPE wasn't doing 2547, then it wouldn't be
> injecting routes, you'd
> have it statically routed and you wouldn't have to worry about what
> your customer was
> doing to you.  Deploying 2547 in the first place elevates each and
> every customer to having
> the same kind of care and feeding that providers give each other,
> without the full
> time technical networking staff on the other side.  Limiting their
> prefixes in number
> is one constraint that you're applying to them, but it cannot be all.
> Will you also
> flap dampen their prefixes?  Do you advertise your flap parameters to
> them too?
>
> Let's not turn BGP into our UNI please.
>
> Tony
>
>
> On May 14, 2004, at 11:56 AM, Fang, Luyuan, ALABS wrote:
>
>> I second Jerry, Mo, and Sue for supporting
>> draft-chavali-bgp-prefixlimit-02.txt to become WG document.
>>
>> This draft presented the "three level threshold" approach (started
>> from first version presented in IETF 58) which makes the prefix limit
>> control to be proactive instead of passive as it is today. This can
>> help the providers to minimize service interruption, lower operational
>> cost and complexity.
>>
>> In the current implementation, the prefix limit is only configured on
>> the BGP receiver (e.g., provider edge router), the BGP speaker (e.g.
>> CPE) does not have any control. Some implementation has warning
>> threshold option. When warning limit is reached, the trap will only
>> show up on the provider side, the operator has to contact the customer
>> by phone or through some messaging systems. When the drop limit is
>> reached, provider edge router would drop the session. (Some
>> implementation may drop routes which is over the limit from provider
>> side instead of drop session). The operator has to work with the
>> customer to reset the sessions when problems in the customer being
>> fixed. This involves a lot of manual work. In addition, provider have
>> to prove that the session drop was not due to network failure but the
>> customer violated the prefix limit, etc... Being on the network design
>> side, we hear a lot of complains from the operation folks on using the
>> prefix limit feature for customer connections.
>>
>> Due to the intensive work involved, operators often simply not to use
>> the prefix limit feature for connecting customers, especially for
>> Internet services connections. But with network based MPLS/BGP VPNs
>> deployed in recent years, the router resource management became such a
>> critical issue, operators might be forced to use the prefix limit on
>> VPN customer sessions in order to protect the network resources,
>> especially the Provider Edge routers if the platforms have serious
>> scaling issues.
>>
>> With the three level threshold and prefix limit exchange mechanism
>> proposed in this draft, the CPE gets the same three level thresholds
>> as set by Provider edge, the key is that CPE will STOP sending routes
>> when limits are reached, and the customer will the problems in his
>> network, no session drop nor route drop by the provider. Of course, if
>> the CPE does not function correctly and keep sending routes, there is
>> still the last level threshold provides the safe guard - drop (or
>> reset) the session by the provider.
>>
>> This draft described the approach meets the operator's needs of
>> improving service quality, lowering the operation cost and complexity.
>>
>> Luyuan
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]On Behalf Of Ash,
>> Gerald R (Jerry), ALABS
>> Sent: Wednesday, May 12, 2004 8:50 AM
>> To: Yakov Rekhter; [e-mail]
>> Cc: Ash, Gerald R (Jerry), ALABS
>> Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
>> document
>>
>>
>>> Those who were in favor of accepting
>>> draft-chavali-bgp-prefixlimit-01.txt
>>> as an IDR WG document need to say whether they are in
>>> favor of accepting draft-chavali-bgp-prefixlimit-02.txt
>>> as an IDR WG document.
>>
>> Yes, I support this becoming a WG document.  This is a useful
>> operational mechanism, wherein customers receive a warning on the
>> prefix-limit condition and can take action.  This draft proposes a
>> reasonable approach to address the issue.
>>
>> Jerry
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr
>>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA07115 for <[e-mail]>; Fri, 14 May 2004 18:44:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOlEm-0007ri-5y; Fri, 14 May 2004 18:33:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOl9b-0006rs-SH for [e-mail]; Fri, 14 May 2004 18:27:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03536 for <[e-mail]>; Fri, 14 May 2004 18:27:38 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOl9Y-0002Cy-RF for [e-mail]; Fri, 14 May 2004 18:27:40 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOl8f-0001ha-00 for [e-mail]; Fri, 14 May 2004 18:26:47 -0400
Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BOl7u-00019m-00 for [e-mail]; Fri, 14 May 2004 18:25:59 -0400
Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4EMP9MJ017246 for <[e-mail]>; Fri, 14 May 2004 18:25:24 -0400
Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 40A0470400112292; Fri, 14 May 2004 18:25:21 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Thread-Index: AcQ596LR7VBd8RUTT3SESyZmitULoAAA8y+A
From: "Fang, Luyuan, ALABS" <[e-mail]>
To: "Tony Li" <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 14 May 2004 17:25:23 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id SAA07115

I do not want to go into the discussion of BGP should be used for 2547 or not. It is beyond this subject. But I want to say that something has to be used if we want to provide 2547 kind of network based VPN, whether it is BGP, or other existing protocols or create some new protocols, there is no free lunch. Perfect or not, 2547 VPN services are highly on demand by customers, and good revenue sources for providers. The fact is that it is there, in most provider networks worldwide.

If we only want to stay where we were as many years ago, there were many things we did not need to worry about...

The prefix limit needs largely come from box scaling issues. I'd think focusing on getting the routers more powerful, efficient, and capable would be rather helpful. It is providers' job to provide as many enhanced services as possible to their customers, it is vendors' job to make boxes better each year. Customers, providers, and vendors all benefit from the continues evolution/improvement, right?

Luyuan



-----Original Message-----
From: Tony Li [mailto:[e-mail]]
Sent: Friday, May 14, 2004 5:09 PM
To: Fang, Luyuan, ALABS
Cc: Ash, Gerald R (Jerry), ALABS; Yakov Rekhter; [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document



Isn't this just a band-aid to cover up the fundamental architectural 
flaw of mis-using
BGP for 2547?  If the CPE wasn't doing 2547, then it wouldn't be 
injecting routes, you'd
have it statically routed and you wouldn't have to worry about what 
your customer was
doing to you.  Deploying 2547 in the first place elevates each and 
every customer to having
the same kind of care and feeding that providers give each other, 
without the full
time technical networking staff on the other side.  Limiting their 
prefixes in number
is one constraint that you're applying to them, but it cannot be all.  
Will you also
flap dampen their prefixes?  Do you advertise your flap parameters to 
them too?

Let's not turn BGP into our UNI please.

Tony


On May 14, 2004, at 11:56 AM, Fang, Luyuan, ALABS wrote:

> I second Jerry, Mo, and Sue for supporting 
> draft-chavali-bgp-prefixlimit-02.txt to become WG document.
>
> This draft presented the "three level threshold" approach (started 
> from first version presented in IETF 58) which makes the prefix limit 
> control to be proactive instead of passive as it is today. This can 
> help the providers to minimize service interruption, lower operational 
> cost and complexity.
>
> In the current implementation, the prefix limit is only configured on 
> the BGP receiver (e.g., provider edge router), the BGP speaker (e.g. 
> CPE) does not have any control. Some implementation has warning 
> threshold option. When warning limit is reached, the trap will only 
> show up on the provider side, the operator has to contact the customer 
> by phone or through some messaging systems. When the drop limit is 
> reached, provider edge router would drop the session. (Some 
> implementation may drop routes which is over the limit from provider 
> side instead of drop session). The operator has to work with the 
> customer to reset the sessions when problems in the customer being 
> fixed. This involves a lot of manual work. In addition, provider have 
> to prove that the session drop was not due to network failure but the 
> customer violated the prefix limit, etc... Being on the network design 
> side, we hear a lot of complains from the operation folks on using the 
> prefix limit feature for customer connections.
>
> Due to the intensive work involved, operators often simply not to use 
> the prefix limit feature for connecting customers, especially for 
> Internet services connections. But with network based MPLS/BGP VPNs 
> deployed in recent years, the router resource management became such a 
> critical issue, operators might be forced to use the prefix limit on 
> VPN customer sessions in order to protect the network resources, 
> especially the Provider Edge routers if the platforms have serious 
> scaling issues.
>
> With the three level threshold and prefix limit exchange mechanism 
> proposed in this draft, the CPE gets the same three level thresholds 
> as set by Provider edge, the key is that CPE will STOP sending routes 
> when limits are reached, and the customer will the problems in his 
> network, no session drop nor route drop by the provider. Of course, if 
> the CPE does not function correctly and keep sending routes, there is 
> still the last level threshold provides the safe guard - drop (or 
> reset) the session by the provider.
>
> This draft described the approach meets the operator's needs of 
> improving service quality, lowering the operation cost and complexity.
>
> Luyuan
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of Ash,
> Gerald R (Jerry), ALABS
> Sent: Wednesday, May 12, 2004 8:50 AM
> To: Yakov Rekhter; [e-mail]
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
> document
>
>
>> Those who were in favor of accepting
>> draft-chavali-bgp-prefixlimit-01.txt
>> as an IDR WG document need to say whether they are in
>> favor of accepting draft-chavali-bgp-prefixlimit-02.txt
>> as an IDR WG document.
>
> Yes, I support this becoming a WG document.  This is a useful 
> operational mechanism, wherein customers receive a warning on the 
> prefix-limit condition and can take action.  This draft proposes a 
> reasonable approach to address the issue.
>
> Jerry
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA07001 for <[e-mail]>; Fri, 14 May 2004 18:43:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOlES-0007h4-Ky; Fri, 14 May 2004 18:32:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOl0b-0004OR-90 for [e-mail]; Fri, 14 May 2004 18:18:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03107 for <[e-mail]>; Fri, 14 May 2004 18:18:20 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOl0Y-0005W2-80 for [e-mail]; Fri, 14 May 2004 18:18:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOkzZ-00050c-00 for [e-mail]; Fri, 14 May 2004 18:17:22 -0400
Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1BOkyZ-0003zr-00 for [e-mail]; Fri, 14 May 2004 18:16:19 -0400
Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (sccrmhc13) with SMTP id <20040514221538016003pbtme> (Authid: li.tony); Fri, 14 May 2004 22:15:38 +0000
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: "Fang, Luyuan, ALABS" <[e-mail]>, "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
From: Tony Li <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
To: [e-mail]
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 14 May 2004 15:15:37 -0700

Write a cron job that sends them email.  Sheesh.

Tony


On May 14, 2004, at 3:08 PM, Robert Raszuk wrote:

> Tony,
>
> Just for the record I have pure IPv4 nationwide ISP who requested 
> max-prefix "drop excess" action and has nothing to do with 2547 what 
> so ever.
>
> Notifying his own domestic customer that some routes (for example due 
> to mistaken redistribution of full table) are being discarded was just 
> an optional request.
>
> One option is just to call the guys on the phone, send them a mail or 
> send them an ORF msg in an automated way ahead of time. Dropping the 
> session option was not acceptable as their entire domestic 
> connectivity would be cut out.
>
> I think that the max-prefix ORF Type is simple and harmless enough 
> that we should proceed with forward - at least as an IDR WG item. Even 
> if all the recipient would do with this information would be to have 
> this available in the syslog as soon as the threshold is crossed would 
> be an improvement to today's model of operation.
>
> R.
>
>
> > Tony Li wrote:
>> Isn't this just a band-aid to cover up the fundamental architectural 
>> flaw of mis-using BGP for 2547?  If the CPE wasn't doing 2547, then 
>> it wouldn't be injecting routes, you'd have it statically routed and 
>> you wouldn't have to worry about what your customer was doing to you. 
>>  Deploying 2547 in the first place elevates each and every customer 
>> to having the same kind of care and feeding that providers give each 
>> other, without the full time technical networking staff on the other 
>> side.  Limiting their prefixes in number is one constraint that 
>> you're applying to them, but it cannot be all.  Will you also flap 
>> dampen their prefixes?  Do you advertise your flap parameters to them 
>> too?
>> Let's not turn BGP into our UNI please.
>> Tony
>> On May 14, 2004, at 11:56 AM, Fang, Luyuan, ALABS wrote:
>>> I second Jerry, Mo, and Sue for supporting 
>>> draft-chavali-bgp-prefixlimit-02.txt to become WG document.
>>>
>>> This draft presented the "three level threshold" approach (started 
>>> from first version presented in IETF 58) which makes the prefix 
>>> limit control to be proactive instead of passive as it is today. 
>>> This can help the providers to minimize service interruption, lower 
>>> operational cost and complexity.
>>>
>>> In the current implementation, the prefix limit is only configured 
>>> on the BGP receiver (e.g., provider edge router), the BGP speaker 
>>> (e.g. CPE) does not have any control. Some implementation has 
>>> warning threshold option. When warning limit is reached, the trap 
>>> will only show up on the provider side, the operator has to contact 
>>> the customer by phone or through some messaging systems. When the 
>>> drop limit is reached, provider edge router would drop the session. 
>>> (Some implementation may drop routes which is over the limit from 
>>> provider side instead of drop session). The operator has to work 
>>> with the customer to reset the sessions when problems in the 
>>> customer being fixed. This involves a lot of manual work. In 
>>> addition, provider have to prove that the session drop was not due 
>>> to network failure but the customer violated the prefix limit, 
>>> etc... Being on the network design side, we hear a lot of complains 
>>> from the operation folks on using the prefix limit feature for 
>>> customer connections.
>>>
>>> Due to the intensive work involved, operators often simply not to 
>>> use the prefix limit feature for connecting customers, especially 
>>> for Internet services connections. But with network based MPLS/BGP 
>>> VPNs deployed in recent years, the router resource management became 
>>> such a critical issue, operators might be forced to use the prefix 
>>> limit on VPN customer sessions in order to protect the network 
>>> resources, especially the Provider Edge routers if the platforms 
>>> have serious scaling issues.
>>>
>>> With the three level threshold and prefix limit exchange mechanism 
>>> proposed in this draft, the CPE gets the same three level thresholds 
>>> as set by Provider edge, the key is that CPE will STOP sending 
>>> routes when limits are reached, and the customer will the problems 
>>> in his network, no session drop nor route drop by the provider. Of 
>>> course, if the CPE does not function correctly and keep sending 
>>> routes, there is still the last level threshold provides the safe 
>>> guard - drop (or reset) the session by the provider.
>>>
>>> This draft described the approach meets the operator's needs of 
>>> improving service quality, lowering the operation cost and 
>>> complexity.
>>>
>>> Luyuan
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]On Behalf Of Ash,
>>> Gerald R (Jerry), ALABS
>>> Sent: Wednesday, May 12, 2004 8:50 AM
>>> To: Yakov Rekhter; [e-mail]
>>> Cc: Ash, Gerald R (Jerry), ALABS
>>> Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
>>> document
>>>
>>>
>>>> Those who were in favor of accepting
>>>> draft-chavali-bgp-prefixlimit-01.txt
>>>> as an IDR WG document need to say whether they are in
>>>> favor of accepting draft-chavali-bgp-prefixlimit-02.txt
>>>> as an IDR WG document.
>>>
>>>
>>> Yes, I support this becoming a WG document.  This is a useful 
>>> operational mechanism, wherein customers receive a warning on the 
>>> prefix-limit condition and can take action.  This draft proposes a 
>>> reasonable approach to address the issue.
>>>
>>> Jerry
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/idr
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/idr
>>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr
>


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA05589 for <[e-mail]>; Fri, 14 May 2004 18:25:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkwO-0002Fl-7r; Fri, 14 May 2004 18:14:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkst-0000Dp-6L for [e-mail]; Fri, 14 May 2004 18:10:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02184 for <[e-mail]>; Fri, 14 May 2004 18:10:22 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOksq-0001Uf-A3 for [e-mail]; Fri, 14 May 2004 18:10:24 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOks1-0000zv-00 for [e-mail]; Fri, 14 May 2004 18:09:34 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BOkrD-0000Fe-00 for [e-mail]; Fri, 14 May 2004 18:08:43 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 14 May 2004 15:08:04 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4EM8AC1014841; Fri, 14 May 2004 15:08:10 -0700 (PDT)
Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATE92193; Fri, 14 May 2004 15:07:21 -0700 (PDT)
Message-ID: <[e-mail]>
From: Robert Raszuk <[e-mail]>
Reply-To: [e-mail]
Organization: Signature: http://www.employees.org/~raszuk/sig/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Li <[e-mail]>
CC: "Fang, Luyuan, ALABS" <[e-mail]>, "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 14 May 2004 15:08:07 -0700

Tony,

Just for the record I have pure IPv4 nationwide ISP who requested 
max-prefix "drop excess" action and has nothing to do with 2547 what so 
ever.

Notifying his own domestic customer that some routes (for example due to 
mistaken redistribution of full table) are being discarded was just an 
optional request.

One option is just to call the guys on the phone, send them a mail or 
send them an ORF msg in an automated way ahead of time. Dropping the 
session option was not acceptable as their entire domestic connectivity 
would be cut out.

I think that the max-prefix ORF Type is simple and harmless enough that 
we should proceed with forward - at least as an IDR WG item. Even if all 
the recipient would do with this information would be to have this 
available in the syslog as soon as the threshold is crossed would be an 
improvement to today's model of operation.

R.


 > Tony Li wrote:
> 
> Isn't this just a band-aid to cover up the fundamental architectural 
> flaw of mis-using BGP for 2547?  If the CPE wasn't doing 2547, then it wouldn't be 
> injecting routes, you'd have it statically routed and you wouldn't have to worry about what your 
> customer was doing to you.  Deploying 2547 in the first place elevates each and every 
> customer to having the same kind of care and feeding that providers give each other, 
> without the full time technical networking staff on the other side.  Limiting their 
> prefixes in number is one constraint that you're applying to them, but it cannot be all.  
> Will you also flap dampen their prefixes?  Do you advertise your flap parameters to 
> them too?
> 
> Let's not turn BGP into our UNI please.
> 
> Tony
> 
> 
> On May 14, 2004, at 11:56 AM, Fang, Luyuan, ALABS wrote:
> 
>> I second Jerry, Mo, and Sue for supporting 
>> draft-chavali-bgp-prefixlimit-02.txt to become WG document.
>>
>> This draft presented the "three level threshold" approach (started 
>> from first version presented in IETF 58) which makes the prefix limit 
>> control to be proactive instead of passive as it is today. This can 
>> help the providers to minimize service interruption, lower operational 
>> cost and complexity.
>>
>> In the current implementation, the prefix limit is only configured on 
>> the BGP receiver (e.g., provider edge router), the BGP speaker (e.g. 
>> CPE) does not have any control. Some implementation has warning 
>> threshold option. When warning limit is reached, the trap will only 
>> show up on the provider side, the operator has to contact the customer 
>> by phone or through some messaging systems. When the drop limit is 
>> reached, provider edge router would drop the session. (Some 
>> implementation may drop routes which is over the limit from provider 
>> side instead of drop session). The operator has to work with the 
>> customer to reset the sessions when problems in the customer being 
>> fixed. This involves a lot of manual work. In addition, provider have 
>> to prove that the session drop was not due to network failure but the 
>> customer violated the prefix limit, etc... Being on the network design 
>> side, we hear a lot of complains from the operation folks on using the 
>> prefix limit feature for customer connections.
>>
>> Due to the intensive work involved, operators often simply not to use 
>> the prefix limit feature for connecting customers, especially for 
>> Internet services connections. But with network based MPLS/BGP VPNs 
>> deployed in recent years, the router resource management became such a 
>> critical issue, operators might be forced to use the prefix limit on 
>> VPN customer sessions in order to protect the network resources, 
>> especially the Provider Edge routers if the platforms have serious 
>> scaling issues.
>>
>> With the three level threshold and prefix limit exchange mechanism 
>> proposed in this draft, the CPE gets the same three level thresholds 
>> as set by Provider edge, the key is that CPE will STOP sending routes 
>> when limits are reached, and the customer will the problems in his 
>> network, no session drop nor route drop by the provider. Of course, if 
>> the CPE does not function correctly and keep sending routes, there is 
>> still the last level threshold provides the safe guard - drop (or 
>> reset) the session by the provider.
>>
>> This draft described the approach meets the operator's needs of 
>> improving service quality, lowering the operation cost and complexity.
>>
>> Luyuan
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]On Behalf Of Ash,
>> Gerald R (Jerry), ALABS
>> Sent: Wednesday, May 12, 2004 8:50 AM
>> To: Yakov Rekhter; [e-mail]
>> Cc: Ash, Gerald R (Jerry), ALABS
>> Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
>> document
>>
>>
>>> Those who were in favor of accepting
>>> draft-chavali-bgp-prefixlimit-01.txt
>>> as an IDR WG document need to say whether they are in
>>> favor of accepting draft-chavali-bgp-prefixlimit-02.txt
>>> as an IDR WG document.
>>
>>
>> Yes, I support this becoming a WG document.  This is a useful 
>> operational mechanism, wherein customers receive a warning on the 
>> prefix-limit condition and can take action.  This draft proposes a 
>> reasonable approach to address the issue.
>>
>> Jerry
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr
>>
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
> 


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA02148 for <[e-mail]>; Fri, 14 May 2004 17:37:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOk8I-0000FG-N0; Fri, 14 May 2004 17:22:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOk34-0006eY-PU for [e-mail]; Fri, 14 May 2004 17:16:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28024 for <[e-mail]>; Fri, 14 May 2004 17:16:50 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOk32-0004r9-He for [e-mail]; Fri, 14 May 2004 17:16:52 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOk0G-0003Z7-00 for [e-mail]; Fri, 14 May 2004 17:14:01 -0400
Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1BOjvU-00027Z-00 for [e-mail]; Fri, 14 May 2004 17:09:04 -0400
Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (sccrmhc13) with SMTP id <20040514210833016003pl54e> (Authid: li.tony); Fri, 14 May 2004 21:08:34 +0000
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, <[e-mail]>
From: Tony Li <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
To: "Fang, Luyuan, ALABS" <[e-mail]>
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 14 May 2004 14:08:32 -0700

Isn't this just a band-aid to cover up the fundamental architectural 
flaw of mis-using
BGP for 2547?  If the CPE wasn't doing 2547, then it wouldn't be 
injecting routes, you'd
have it statically routed and you wouldn't have to worry about what 
your customer was
doing to you.  Deploying 2547 in the first place elevates each and 
every customer to having
the same kind of care and feeding that providers give each other, 
without the full
time technical networking staff on the other side.  Limiting their 
prefixes in number
is one constraint that you're applying to them, but it cannot be all.  
Will you also
flap dampen their prefixes?  Do you advertise your flap parameters to 
them too?

Let's not turn BGP into our UNI please.

Tony


On May 14, 2004, at 11:56 AM, Fang, Luyuan, ALABS wrote:

> I second Jerry, Mo, and Sue for supporting 
> draft-chavali-bgp-prefixlimit-02.txt to become WG document.
>
> This draft presented the "three level threshold" approach (started 
> from first version presented in IETF 58) which makes the prefix limit 
> control to be proactive instead of passive as it is today. This can 
> help the providers to minimize service interruption, lower operational 
> cost and complexity.
>
> In the current implementation, the prefix limit is only configured on 
> the BGP receiver (e.g., provider edge router), the BGP speaker (e.g. 
> CPE) does not have any control. Some implementation has warning 
> threshold option. When warning limit is reached, the trap will only 
> show up on the provider side, the operator has to contact the customer 
> by phone or through some messaging systems. When the drop limit is 
> reached, provider edge router would drop the session. (Some 
> implementation may drop routes which is over the limit from provider 
> side instead of drop session). The operator has to work with the 
> customer to reset the sessions when problems in the customer being 
> fixed. This involves a lot of manual work. In addition, provider have 
> to prove that the session drop was not due to network failure but the 
> customer violated the prefix limit, etc... Being on the network design 
> side, we hear a lot of complains from the operation folks on using the 
> prefix limit feature for customer connections.
>
> Due to the intensive work involved, operators often simply not to use 
> the prefix limit feature for connecting customers, especially for 
> Internet services connections. But with network based MPLS/BGP VPNs 
> deployed in recent years, the router resource management became such a 
> critical issue, operators might be forced to use the prefix limit on 
> VPN customer sessions in order to protect the network resources, 
> especially the Provider Edge routers if the platforms have serious 
> scaling issues.
>
> With the three level threshold and prefix limit exchange mechanism 
> proposed in this draft, the CPE gets the same three level thresholds 
> as set by Provider edge, the key is that CPE will STOP sending routes 
> when limits are reached, and the customer will the problems in his 
> network, no session drop nor route drop by the provider. Of course, if 
> the CPE does not function correctly and keep sending routes, there is 
> still the last level threshold provides the safe guard - drop (or 
> reset) the session by the provider.
>
> This draft described the approach meets the operator's needs of 
> improving service quality, lowering the operation cost and complexity.
>
> Luyuan
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of Ash,
> Gerald R (Jerry), ALABS
> Sent: Wednesday, May 12, 2004 8:50 AM
> To: Yakov Rekhter; [e-mail]
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
> document
>
>
>> Those who were in favor of accepting
>> draft-chavali-bgp-prefixlimit-01.txt
>> as an IDR WG document need to say whether they are in
>> favor of accepting draft-chavali-bgp-prefixlimit-02.txt
>> as an IDR WG document.
>
> Yes, I support this becoming a WG document.  This is a useful 
> operational mechanism, wherein customers receive a warning on the 
> prefix-limit condition and can take action.  This draft proposes a 
> reasonable approach to address the issue.
>
> Jerry
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA19904 for <[e-mail]>; Fri, 14 May 2004 15:08:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhyV-0007Bz-8H; Fri, 14 May 2004 15:04:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhux-00036z-1P for [e-mail]; Fri, 14 May 2004 15:00:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14323 for <[e-mail]>; Fri, 14 May 2004 15:00:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOhuu-0004Cd-0b for [e-mail]; Fri, 14 May 2004 15:00:20 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOhu2-0003ej-00 for [e-mail]; Fri, 14 May 2004 14:59:27 -0400
Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BOhrt-0002Dl-00 for [e-mail]; Fri, 14 May 2004 14:57:14 -0400
Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4EItDSb028339 for <[e-mail]>; Fri, 14 May 2004 13:56:42 -0500
Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 40A0470400104923; Fri, 14 May 2004 14:56:39 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Thread-Index: AcQ2l5kp+ovvWlxRRuy/vb3/bYKjbQBhpbvwAG/pvKA=
From: "Fang, Luyuan, ALABS" <[e-mail]>
To: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 14 May 2004 13:56:41 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA19904

I second Jerry, Mo, and Sue for supporting draft-chavali-bgp-prefixlimit-02.txt to become WG document. 

This draft presented the "three level threshold" approach (started from first version presented in IETF 58) which makes the prefix limit control to be proactive instead of passive as it is today. This can help the providers to minimize service interruption, lower operational cost and complexity.

In the current implementation, the prefix limit is only configured on the BGP receiver (e.g., provider edge router), the BGP speaker (e.g. CPE) does not have any control. Some implementation has warning threshold option. When warning limit is reached, the trap will only show up on the provider side, the operator has to contact the customer by phone or through some messaging systems. When the drop limit is reached, provider edge router would drop the session. (Some implementation may drop routes which is over the limit from provider side instead of drop session). The operator has to work with the customer to reset the sessions when problems in the customer being fixed. This involves a lot of manual work. In addition, provider have to prove that the session drop was not due to network failure but the customer violated the prefix limit, etc... Being on the network design side, we hear a lot of complains from the operation folks on using the prefix limit feature for customer connections. 

Due to the intensive work involved, operators often simply not to use the prefix limit feature for connecting customers, especially for Internet services connections. But with network based MPLS/BGP VPNs deployed in recent years, the router resource management became such a critical issue, operators might be forced to use the prefix limit on VPN customer sessions in order to protect the network resources, especially the Provider Edge routers if the platforms have serious scaling issues.

With the three level threshold and prefix limit exchange mechanism proposed in this draft, the CPE gets the same three level thresholds as set by Provider edge, the key is that CPE will STOP sending routes when limits are reached, and the customer will the problems in his network, no session drop nor route drop by the provider. Of course, if the CPE does not function correctly and keep sending routes, there is still the last level threshold provides the safe guard - drop (or reset) the session by the provider.

This draft described the approach meets the operator's needs of improving service quality, lowering the operation cost and complexity. 

Luyuan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of Ash,
Gerald R (Jerry), ALABS
Sent: Wednesday, May 12, 2004 8:50 AM
To: Yakov Rekhter; [e-mail]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document


> Those who were in favor of accepting 
> draft-chavali-bgp-prefixlimit-01.txt
> as an IDR WG document need to say whether they are in
> favor of accepting draft-chavali-bgp-prefixlimit-02.txt
> as an IDR WG document.

Yes, I support this becoming a WG document.  This is a useful operational mechanism, wherein customers receive a warning on the prefix-limit condition and can take action.  This draft proposes a reasonable approach to address the issue.

Jerry

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

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA13714 for <[e-mail]>; Fri, 14 May 2004 13:53:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgl0-0004Jb-TU; Fri, 14 May 2004 13:46:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOghQ-0003ga-MZ for [e-mail]; Fri, 14 May 2004 13:42:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07823 for <[e-mail]>; Fri, 14 May 2004 13:42:17 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOghO-0004cW-H7 for [e-mail]; Fri, 14 May 2004 13:42:18 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOggQ-00047y-00 for [e-mail]; Fri, 14 May 2004 13:41:19 -0400
Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1BOgfu-0003bZ-00 for [e-mail]; Fri, 14 May 2004 13:40:46 -0400
Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (sccrmhc12) with SMTP id <2004051417400901200t8f39e> (Authid: li.tony); Fri, 14 May 2004 17:40:10 +0000
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
From: Tony Li <[e-mail]>
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
To: Jeffrey Haas <[e-mail]>
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 14 May 2004 10:40:09 -0700

Understood.  My question has much more to do with minimalist design 
principles.
If this is something that doesn't HAVE to be there, then it probably 
shouldn't
be.

What's next?  Do we signal the amount of memory that an implementation 
has left
before it chokes?  How about current CPU utilization?  The phase of the 
moon?

This really smells like hump of camel to me.

Tony


On May 14, 2004, at 8:59 AM, Jeffrey Haas wrote:

> Tony,
>
> On Tue, May 11, 2004 at 05:08:13PM -0700, Tony Li wrote:
>> FWIW, I'm having a hard time understanding why we want the prefix 
>> limit
>> signaled.
>
> Completely aside from taking some form of remedial step on receipt
> of your peer's prefix-limit for you (which is the majority of
> where the arguments are happening), this allows for your implementation
> to be able to monitor its adj-rib-out count for the peer and to
> let management applications (probably SNMP) warn operators when you're
> going to hit this limit.
>
> Sure, you could configure this, on your side, but I would wonder if
> that would be anywhere near as useful.
>
> I believe this is the point that Tao was making.
>
> -- 
> Jeff Haas
> NextHop Technologies
>


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA12258 for <[e-mail]>; Fri, 14 May 2004 13:35:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgVZ-0000mF-BE; Fri, 14 May 2004 13:30:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgPG-0007oI-F6 for [e-mail]; Fri, 14 May 2004 13:23:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06672 for <[e-mail]>; Fri, 14 May 2004 13:23:31 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOgPE-0002jR-Ak for [e-mail]; Fri, 14 May 2004 13:23:32 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOgN7-0001je-00 for [e-mail]; Fri, 14 May 2004 13:21:21 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BOgM2-0001BI-00 for [e-mail]; Fri, 14 May 2004 13:20:14 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4EHHCaL056466; Fri, 14 May 2004 13:17:12 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
cc: Tony Li <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item 
In-reply-to: Your message of "Fri, 14 May 2004 11:59:02 EDT." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 14 May 2004 13:17:12 -0400

In message <[e-mail]>, Jeffrey Haas writes:
> Tony,
> 
> On Tue, May 11, 2004 at 05:08:13PM -0700, Tony Li wrote:
> > FWIW, I'm having a hard time understanding why we want the prefix limit 
> > signaled.
> 
> Completely aside from taking some form of remedial step on receipt
> of your peer's prefix-limit for you (which is the majority of
> where the arguments are happening), this allows for your implementation
> to be able to monitor its adj-rib-out count for the peer and to
> let management applications (probably SNMP) warn operators when you're
> going to hit this limit.
> 
> Sure, you could configure this, on your side, but I would wonder if
> that would be anywhere near as useful.
> 
> I believe this is the point that Tao was making.
> 
> -- 
> Jeff Haas 
> NextHop Technologies



Having in a past life been an operator I remember that a massive
number of SNMP traps can be generated and no human being is sitting
there looking at them all, but there are programs that look through
them and pick out ones that need attention (some polling to follow up,
and depending on what is found maybe a trouble ticket).

I can think of two cases where prefix limits could come into play and
one side or the other needs to take action.  With static
configuration, the configuration could be different on each side.  One
side may be notified by SNMP that there is a problem but that side may
not be aware that there is a problem because of limitations of their
SNMP trap handler or may be slow to pass the notification to the other
side.

The classic prefix-limit problem is when your peer goofs and
advertises a lot of routes that they have no business advertising.
This could just be a goofed hand edit on a policy statement.  The
assumption is that you are protecting yourself from your peer's goof.
It would also help if the party that goofed got direct notification
rather than NOC to NOC communication that the limit was exceeded.  For
this you need notification on both sides when the limit is exceeded.

Where advertising the prefix limit itself helps is if the prefix limit
is configured too low or wrong on the other side or changed for some
reason without telling the peer.  If you are sending legitimate routes
to your peer and you hit a 80% or 90% threshhold on the advertised
prefix-limit you may want to negociate a higher limit with your peer.
Its better to do this at the 80% mark than wait for an outage and for
your peer to tell you that they have finally discovered that the
problem all along was that they had configured too low a prefix limit.
It also helps to know that a limit that was agreed to by your peer was
actually configured on the other side.

Curtis

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06474 for <[e-mail]>; Fri, 14 May 2004 12:23:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOfOn-00035V-32; Fri, 14 May 2004 12:19:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOf7T-0006wq-2K for [e-mail]; Fri, 14 May 2004 12:01:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29255 for <[e-mail]>; Fri, 14 May 2004 12:01:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOf7R-0003gI-Ql for [e-mail]; Fri, 14 May 2004 12:01:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOf6Y-0003DI-00 for [e-mail]; Fri, 14 May 2004 12:00:10 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BOf6A-0002je-00 for [e-mail]; Fri, 14 May 2004 11:59:46 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 41DC22D48C4; Fri, 14 May 2004 11:59:16 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43789-01-7; Fri, 14 May 2004 11:59:04 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D38332D4825; Fri, 14 May 2004 11:59:04 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i4EFx2P28296; Fri, 14 May 2004 11:59:02 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Tony Li <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, May 11, 2004 at 05:08:13PM -0700
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 14 May 2004 11:59:02 -0400

Tony,

On Tue, May 11, 2004 at 05:08:13PM -0700, Tony Li wrote:
> FWIW, I'm having a hard time understanding why we want the prefix limit 
> signaled.

Completely aside from taking some form of remedial step on receipt
of your peer's prefix-limit for you (which is the majority of
where the arguments are happening), this allows for your implementation
to be able to monitor its adj-rib-out count for the peer and to
let management applications (probably SNMP) warn operators when you're
going to hit this limit.

Sure, you could configure this, on your side, but I would wonder if
that would be anywhere near as useful.

I believe this is the point that Tao was making.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02136 for <[e-mail]>; Fri, 14 May 2004 11:29:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeZV-0007w9-41; Fri, 14 May 2004 11:26:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeS9-0006ek-GK for [e-mail]; Fri, 14 May 2004 11:18:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27315 for <[e-mail]>; Fri, 14 May 2004 11:18:22 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOeS8-0005eZ-8M for [e-mail]; Fri, 14 May 2004 11:18:24 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOeQw-00058l-00 for [e-mail]; Fri, 14 May 2004 11:17:11 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BOePu-0004BC-00 for [e-mail]; Fri, 14 May 2004 11:16:06 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 418222D4838 for <[e-mail]>; Fri, 14 May 2004 11:15:34 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42417-01-13 for <[e-mail]>; Fri, 14 May 2004 11:15:22 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 19FA42D491E for <[e-mail]>; Fri, 14 May 2004 11:15:01 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C439C6.39BD5EDA"
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Thread-Index: AcQ4oFzG9Hc35n/yQY+wbeoVob23rQBIp6Lg
From: "Susan Hares" <[e-mail]>
To: "Enrico Salazar" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no  version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 14 May 2004 11:15:00 -0400

This is a multi-part message in MIME format.

------_=_NextPart_001_01C439C6.39BD5EDA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Enrico:
=20
Thank you for your comments. =20
Yakov and I appreciate the input.
=20
Could you let me know if you are:
a) vendor  b) network operator or
c) valued researcher/expert=20
or d) other?
=20
Sue=20

-----Original Message-----
From: Enrico Salazar [mailto:[e-mail]]
Sent: Wednesday, May 12, 2004 9:49 PM
To: Yakov Rekhter; [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG =
document


I object to taking signalled prefix limit, as I think that the existing =
mechanisms are sufficient to handle real-life scenarios (see
Pekka's e-mail).
=20
If there is an agreement that there are real-life scenarios that
require signalled prefix limit, then I would be in favor of accepting
draft-keyur-prefixlimit-orf-00.txt.
=20
I object accepting draft-chavali-bgp-prefixlimit-02.txt.
=20
   Enrico


Yakov Rekhter <[e-mail]> wrote:

Folks,

Given the current discussion on the mailing list, the deadline
for comments on accepting draft-chavali-bgp-prefixlimit-02.txt
as an IDR WG document is extended to May 24, 2004.

This way May 24 is the deadline for comments on the following:

1. whether to take signalled prefix limit as a WG item

2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR
WG document

3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR
WG document

In your e-mails please clearly indicate your preferences. Providing
rationale for your preferences would be extremely useful as well.

Yakov.

P.S If folks feel that the deadline should be extended beyond
May 24, please say so.

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



  _____ =20

Do you Yahoo!?
Yahoo! Movies - Buy advance  =
<http://movies.yahoo.com/showtimes/movie?mid=3D1808405861> tickets for =
'Shrek 2'=20


------_=_NextPart_001_01C439C6.39BD5EDA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D631475114-14052004>Enrico:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D631475114-14052004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D631475114-14052004>Thank=20
you for your comments.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D631475114-14052004>Yakov=20
and I appreciate the input.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D631475114-14052004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D631475114-14052004>Could=20
you let me know if you are:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D631475114-14052004>a)=20
vendor&nbsp; b) network operator or</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D631475114-14052004>c)=20
valued researcher/expert </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D631475114-14052004>or d)=20
other?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D631475114-14052004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D631475114-14052004>Sue=20
</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Enrico Salazar=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 12, 2004 =
9:49=20
  PM<BR><B>To:</B> Yakov Rekhter; [e-mail]<BR><B>Subject:</B> Re: =
[Idr]=20
  draft-chavali-bgp-prefixlimit-02.txt as an IDR WG=20
document<BR><BR></FONT></DIV>
  <DIV>I&nbsp;object to&nbsp;taking signalled prefix limit, as I think =
that the=20
  existing mechanisms are sufficient to handle real-life scenarios=20
  (see<BR>Pekka's e-mail).</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>If there is an agreement that there are real-life scenarios=20
  that<BR>require signalled prefix limit, then I would be in favor of=20
  accepting<BR>draft-keyur-prefixlimit-orf-00.txt.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>I&nbsp;object accepting =
draft-chavali-bgp-prefixlimit-02.txt.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp; Enrico<BR><BR><BR><B><I>Yakov Rekhter=20
  &lt;[e-mail]&gt;</I></B> wrote:</DIV>
  <BLOCKQUOTE class=3Dreplbq=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px =
solid">Folks,<BR><BR>Given=20
    the current discussion on the mailing list, the deadline<BR>for =
comments on=20
    accepting draft-chavali-bgp-prefixlimit-02.txt<BR>as an IDR WG =
document is=20
    extended to May 24, 2004.<BR><BR>This way May 24 is the deadline for =

    comments on the following:<BR><BR>1. whether to take signalled =
prefix limit=20
    as a WG item<BR><BR>2. whether to accept=20
    draft-chavali-bgp-prefixlimit-02.txt as an IDR<BR>WG =
document<BR><BR>3.=20
    whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR<BR>WG =

    document<BR><BR>In your e-mails please clearly indicate your =
preferences.=20
    Providing<BR>rationale for your preferences would be extremely =
useful as=20
    well.<BR><BR>Yakov.<BR><BR>P.S If folks feel that the deadline =
should be=20
    extended beyond<BR>May 24, please say=20
    so.<BR><BR>_______________________________________________<BR>Idr =
mailing=20
    =
list<BR>[e-mail]<BR>https://www1.ietf.org/mailman/listinfo/idr</BLOCK=
QUOTE>
  <P>
  <HR SIZE=3D1>
  <FONT face=3Darial size=3D-1>Do you Yahoo!?<BR>Yahoo! Movies - <A=20
  href=3D"http://movies.yahoo.com/showtimes/movie?mid=3D1808405861">Buy =
advance=20
  tickets for 'Shrek 2' </A></FONT></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C439C6.39BD5EDA--

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA26112 for <[e-mail]>; Thu, 13 May 2004 14:00:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJz5-0005dx-8x; Thu, 13 May 2004 13:27:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJax-0004ws-MO for [e-mail]; Thu, 13 May 2004 13:02:07 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23588; Thu, 13 May 2004 13:02:03 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2796bis-01.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 13 May 2004 13:02:03 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP Route Reflection - An Alternative to Full Mesh IBGP
	Author(s)	: T. Bates, et al. 
	Filename	: draft-ietf-idr-rfc2796bis-01.txt
	Pages		: 12
	Date		: 2004-5-12
	
The Border Gateway Protocol (BGP) is an inter-autonomous system
   routing protocol designed for TCP/IP internets. Typically all BGP
   speakers within a single AS must be fully meshed so that any external
   routing information must be re-distributed to all other routers
   within that AS. This represents a serious scaling problem that has
   been well documented with several alternatives proposed.

   This document describes the use and design of a method known as
   "Route Reflection" to alleviate the the need for "full mesh" IBGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ietf-idr-rfc2796bis-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-rfc2796bis-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.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-rfc2796bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-rfc2796bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA06699 for <[e-mail]>; Thu, 13 May 2004 00:10:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO7Tt-00026K-22; Thu, 13 May 2004 00:06:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO7Rg-0001hs-Vp for [e-mail]; Thu, 13 May 2004 00:03:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00922 for <[e-mail]>; Thu, 13 May 2004 00:03:42 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO7Re-0003Rw-Ma for [e-mail]; Thu, 13 May 2004 00:03:42 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO7Qi-0002xX-00 for [e-mail]; Thu, 13 May 2004 00:02:45 -0400
Received: from web51001.mail.yahoo.com ([206.190.38.132]) by ietf-mx with smtp (Exim 4.12) id 1BO7Q4-0002RJ-00 for [e-mail]; Thu, 13 May 2004 00:02:09 -0400
Message-ID: <[e-mail]>
Received: from [207.17.136.150] by web51001.mail.yahoo.com via HTTP; Wed, 12 May 2004 18:49:26 PDT
From: Enrico Salazar <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
To: Yakov Rekhter <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-351530362-1084412966=:97411"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 12 May 2004 18:49:26 -0700 (PDT)

--0-351530362-1084412966=:97411
Content-Type: text/plain; charset=us-ascii

I object to taking signalled prefix limit, as I think that the existing mechanisms are sufficient to handle real-life scenarios (see
Pekka's e-mail).
 
If there is an agreement that there are real-life scenarios that
require signalled prefix limit, then I would be in favor of accepting
draft-keyur-prefixlimit-orf-00.txt.
 
I object accepting draft-chavali-bgp-prefixlimit-02.txt.
 
   Enrico


Yakov Rekhter <[e-mail]> wrote:
Folks,

Given the current discussion on the mailing list, the deadline
for comments on accepting draft-chavali-bgp-prefixlimit-02.txt
as an IDR WG document is extended to May 24, 2004.

This way May 24 is the deadline for comments on the following:

1. whether to take signalled prefix limit as a WG item

2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR
WG document

3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR
WG document

In your e-mails please clearly indicate your preferences. Providing
rationale for your preferences would be extremely useful as well.

Yakov.

P.S If folks feel that the deadline should be extended beyond
May 24, please say so.

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr
		
---------------------------------
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2' 
--0-351530362-1084412966=:97411
Content-Type: text/html; charset=us-ascii

<DIV>I&nbsp;object to&nbsp;taking signalled prefix limit, as I think that the existing mechanisms are sufficient to handle real-life scenarios (see<BR>Pekka's e-mail).</DIV>
<DIV>&nbsp;</DIV>
<DIV>If there is an agreement that there are real-life scenarios that<BR>require signalled prefix limit, then I would be in favor of accepting<BR>draft-keyur-prefixlimit-orf-00.txt.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I&nbsp;object accepting draft-chavali-bgp-prefixlimit-02.txt.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; Enrico<BR><BR><BR><B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Folks,<BR><BR>Given the current discussion on the mailing list, the deadline<BR>for comments on accepting draft-chavali-bgp-prefixlimit-02.txt<BR>as an IDR WG document is extended to May 24, 2004.<BR><BR>This way May 24 is the deadline for comments on the following:<BR><BR>1. whether to take signalled prefix limit as a WG item<BR><BR>2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR<BR>WG document<BR><BR>3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR<BR>WG document<BR><BR>In your e-mails please clearly indicate your preferences. Providing<BR>rationale for your preferences would be extremely useful as well.<BR><BR>Yakov.<BR><BR>P.S If folks feel that the deadline should be extended beyond<BR>May 24, please say so.<BR><BR>_______________________________________________<BR>Idr mailing
 list<BR>[e-mail]<BR>https://www1.ietf.org/mailman/listinfo/idr</BLOCKQUOTE><p>
		<hr size=1><font face=arial size=-1>Do you Yahoo!?<br>Yahoo! Movies - <a href="http://movies.yahoo.com/showtimes/movie?mid=1808405861">Buy advance tickets for 'Shrek 2' </a>
--0-351530362-1084412966=:97411--

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA17293 for <[e-mail]>; Wed, 12 May 2004 15:30:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzHx-0006XR-UM; Wed, 12 May 2004 15:21:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNz7V-0000T6-G6 for [e-mail]; Wed, 12 May 2004 15:10:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01244 for <[e-mail]>; Wed, 12 May 2004 14:21:39 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNyMN-0007C1-2d for [e-mail]; Wed, 12 May 2004 14:21:39 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNyLM-0006gv-00 for [e-mail]; Wed, 12 May 2004 14:20:36 -0400
Received: from mproxy.gmail.com ([216.239.56.245]) by ietf-mx with smtp (Exim 4.12) id 1BNyKN-000689-00 for [e-mail]; Wed, 12 May 2004 14:19:35 -0400
Received: by mproxy.gmail.com with SMTP id x43so9859cwb for <[e-mail]>; Wed, 12 May 2004 11:19:13 -0700 (PDT)
Received: by 10.11.122.64 with SMTP id u64mr48793cwc; Wed, 12 May 2004 11:19:13 -0700 (PDT)
Message-ID: <[e-mail]>
From: Vivek Menezes <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-bgp-multisession-00.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 12 May 2004 11:19:13 -0700

Hi, Just took a look at your draft. This may be  a good opportunity to
also explore
the possibility of having multiple sessions for the same AFI/SAFI. I can see
vendors wanting to have multiple sessions terminating on different
route processors
for fault tolerance. I suppose one could argue using a separate IP for
that, and thats
probably a good solution.

You might want to add other motivations for doing this, such as head
of a line blocking
on the sender side, protocols with larger messages affecting convergence times
of protocols with shorter messaging,

Vivek.

On Wed, 12 May 2004 10:12:25 -0400, [e-mail]
<[e-mail]> wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Inter-Domain Routing Working Group of the IETF.
> 
>         Title           : Multisession BGP
>         Author(s)       : J. Scudder, C. Appanna
>         Filename        : draft-ietf-idr-bgp-multisession-00.txt
>         Pages           : 11
>         Date            : 2004-5-6
> 
> This specification augments "Multiprotocol Extensions for BGP-4" [MP-
>    BGP] by proposing a mechanism to allow multiple sessions to be used
>    between a given pair of BGP speakers.  Each session is used to
>    transport routes for one or more AFI/SAFI.  This provides an
>    alternative to the current [MP-BGP] approach of multiplexing routes
>    for all AFI/SAFI onto a single connection.
> 
>    Use of this approach is expected to increase the robustness of the
>    BGP protocol as it is used to support more and more diverse AFI/SAFI.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-multisession-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] 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-ietf-idr-bgp-multisession-00.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:
>         [e-mail].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-idr-bgp-multisession-00.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.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03496 for <[e-mail]>; Wed, 12 May 2004 13:03:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwrr-0005dC-7L; Wed, 12 May 2004 12:46:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwg4-0000Nk-Bh for [e-mail]; Wed, 12 May 2004 12:33:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23950 for <[e-mail]>; Wed, 12 May 2004 12:33:49 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNwg2-0006j9-UG for [e-mail]; Wed, 12 May 2004 12:33:50 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNwd6-0005L5-00 for [e-mail]; Wed, 12 May 2004 12:30:49 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNwbS-0004TK-00 for [e-mail]; Wed, 12 May 2004 12:29:06 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 838342D4844 for <[e-mail]>; Wed, 12 May 2004 12:28:36 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 67248-01-35 for <[e-mail]>; Wed, 12 May 2004 12:28:24 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 384A12D4830 for <[e-mail]>; Wed, 12 May 2004 12:28:24 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] signalled prefix limit as an IDR WG work item
Thread-Index: AcQ4OuKkDA49jbqaTfaC9xNsLNqhJAAAXQLw
From: "Susan Hares" <[e-mail]>
To: "sun tao" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR  autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 12 May 2004 12:28:23 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA03496

Tao:

<working group chair hat on>
To summarize your response:

1) Work item: yes
2) draft-chavali-bgp-prefixlimit-02.txt - no
3) keyur-prefixlimit-orf-00.txt - yes

Extra comment: prefix limit should be in
		   ORF MIB event.

<working group chair hat off> 
<co-author hat on> 
I just want to confirm that you
want 1 limit per ORF.  You want
to hit the limit and either disconnect
or ignore prefixes.
<co-author hat off> 

Thanks for your comments,

Sue

-----Original Message-----
From: sun tao [mailto:[e-mail]]
Sent: Wednesday, May 12, 2004 10:33 AM
To: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item


hello!
    >> Yakov Rekhter writes:
> 
> > Those who think that the IDR WG should not take signalled prefix
> > limit as a work item, please speak up now.
    if only the MIB reason,We have the same request for the mib to monitor the ORF event.So I think the ORF way to complete the prefix limit should be include the ORF event mib too.from the  operation complex,I think the draft-keyur-prefixlimit-orf-00.txt is easy to realize and configure.we needn't do other thing than add new orf  type.
                                                                                                                                                                                    best 
                                                                                                                                                                                                            tao
----- Original Message ----- 
From: "Pedro Roque Marques" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, May 11, 2004 1:33 AM
Subject: [Idr] signalled prefix limit as an IDR WG work item


> Yakov Rekhter writes:
> 
> > Those who think that the IDR WG should not take signalled prefix
> > limit as a work item, please speak up now.
> 
> It all depends on what is the expectation. I undertand the fact that
> managing prefix-limits of costumer connections is a significant
> operational problem.
> 
> What is not clear to me is what is the expected service model for this
> after signalled prefix limits are agreed.
> 
> My understanding is that different people have different expectations
> regarding what the mecanism is supposed to acomplish.
> 
> i.e. is the point simply to generate a warning limit in the customer
> syste
> 
> or is the fact that the limit is signaled something that just makes
> life easier to the manager of the customer box ?
> 
> or is it a question of transfer of responsability for the session
> reset ?
> 
> or is the expectation that the routers be inteligent enought to
> understand which prefixes are "good" and should be mainatained and
> which prefixes are "bad" and should be droped.
> 
> The latter is quite hard to define and not simple to implement in a
> fail-proof way.
> 
> I would like to clearly define the problem and expectations before we
> solve it... keep in mind that the more complex the problem definition
> the higher the cost of a solution (and thus less likely to come
> about).
> 
>   Pedro.  
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
> 
> 
!jz²®~?³Ãz®jjS

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA01956 for <[e-mail]>; Wed, 12 May 2004 12:46:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwl3-0002NA-Pz; Wed, 12 May 2004 12:39:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwUh-0003eL-6H for [e-mail]; Wed, 12 May 2004 12:22:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22996 for <[e-mail]>; Wed, 12 May 2004 12:22:04 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNwUf-0000u8-M8 for [e-mail]; Wed, 12 May 2004 12:22:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNwTM-0000Lm-00 for [e-mail]; Wed, 12 May 2004 12:20:45 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNwSZ-0007EC-00 for [e-mail]; Wed, 12 May 2004 12:19:55 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D1FE62D482D for <[e-mail]>; Wed, 12 May 2004 12:19:20 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 67487-01-12 for <[e-mail]>; Wed, 12 May 2004 12:19:07 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 81BA32D4844 for <[e-mail]>; Wed, 12 May 2004 12:19:07 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] signalled prefix limit as an IDR WG work item
Thread-Index: AcQ4OW+7c6mPqtmnQQe9xpCtG6gn8wAA2IIw
From: "Susan Hares" <[e-mail]>
To: "Parantap Lahiri" <[e-mail]>, "Jeffrey Haas" <[e-mail]>, "Pedro Roque Marques" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 12 May 2004 12:19:06 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id MAA01956

Parantap:

Thanks for your input. 

Sue

-----Original Message-----
From: Parantap Lahiri [mailto:[e-mail]]
Sent: Wednesday, May 12, 2004 11:53 AM
To: Susan Hares; Jeffrey Haas; 'Pedro Roque Marques'
Cc: [e-mail]
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item


Sue,

Setting warning/stop levels on individual prefix might get too hard to
manage. I am fine with global limits as far as the levels go. 

>Do you also want a Disconnect in case
>of /8 and lots of prefix?

Even after filtering the more specifics if the number of prefixes crosses
the global upperbound limit, I think the session should be taken down. 

-Parantap

-----Original Message-----
From: Susan Hares [mailto:[e-mail]] 
Sent: Tuesday, May 11, 2004 7:15 PM
To: Parantap Lahiri; Jeffrey Haas; Pedro Roque Marques
Cc: [e-mail]
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item

Parantap:

So, you want by individual prefix (not
prefix length, not maximum)

1) Warning level
2) Stop level (Ignore further prefix)

Do you also want a Disconnect in case
of /8 and lots of prefix?

My understanding from the information below
is that you want: global limits (0/0 and
anything that refines it) as well as
these local limits.

Is that correct?

Sue 

-----Original Message-----
From: Parantap Lahiri [mailto:[e-mail]]
Sent: Tuesday, May 11, 2004 3:23 PM
To: Jeffrey Haas; 'Pedro Roque Marques'
Cc: [e-mail]
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item


Here is a couple of paragraphs from a mail I dropped to this list some time
back which relates to this discussion ..

Typically though, the SP accepts any prefixes which are more specific to the
ones maintained in the prefix-list filter. The problem arises when the
customer accidentally de-aggregates their prefixes. And when that happens
depending on the block that got de-aggregated, the number of prefixes send
by customer could experience a sudden sizeable jump. In today's world, there
is a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session
would go down permanently if the max-prefix-limit is exceeded. It would take
an urgent operator intervention to bring it up again, of course the operator
would need to make sure the cause has been taken care off before bringing
the session up.

So if we want to use the draft approach to take care of this particular
scenario, a filtering mechanism depending on the specificity of a prefix
could become important. For, e.g., if a session hits the stop level, the
sender could resend all its prefixes after filtering out any prefix more
specific to /24 etc. Of course this specificity should be configurable.
However, if for example, /24 is chosen, it would ensure all the customer
prefixes are still globally routable, but some of their load-balancing
mechanism can get affected. So the price the customer pays for the mishap
gets less harsh.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jeffrey
Haas
Sent: Tuesday, May 11, 2004 2:51 PM
To: Pedro Roque Marques
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item

On Tue, May 11, 2004 at 10:44:49AM -0700, Pedro Roque Marques wrote:
> Does anyone want to venture how this external knowledge would be
> learned or what would it need to consist off ?

[...]

> For instance if this 'external knowledge' is the exact list of
> prefixes to be allowed, then the entire problem of prefix limits makes
> no sense. i.e. prefix-limits themselfs seem to have been designed to
> deal w/ situations where you have incomplete information.

Perhaps.

One specific example I've heard is that a customer gives their
prefixes they wish to provide to their ISP.  The ISP will permit
those and less specifics to be advertised.  They may also permit
a small number of prefixes to be advertised that are not in this
list.  This permits a new customer to be setup downstream of
the limited connection without the need to immediately update the
list.

(Think of the situation where the NOC of the upstream is slow about
updating these lists.  I think in an ideal world, this would be
dealt with using IRR technology but I'll stick to what we have now.)

In the case of a route explosion, prefer the configured prefixes in
the list and let the others drop.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

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


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


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA01157 for <[e-mail]>; Wed, 12 May 2004 12:39:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwUm-0003jZ-71; Wed, 12 May 2004 12:22:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNw9T-0000Hp-2R for [e-mail]; Wed, 12 May 2004 12:00:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20927 for <[e-mail]>; Wed, 12 May 2004 12:00:08 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNw9R-0005hl-PF for [e-mail]; Wed, 12 May 2004 12:00:09 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNw79-0004ej-00 for [e-mail]; Wed, 12 May 2004 11:57:48 -0400
Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BNw4L-0003Vp-00 for [e-mail]; Wed, 12 May 2004 11:54:53 -0400
Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <[e-mail]> for [e-mail]; Wed, 12 May 2004 15:54:23 +0000 (GMT)
Received: from dgismtp03.wcomnet.com by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <[e-mail]>; Wed, 12 May 2004 15:54:23 +0000 (GMT)
Received: from WS344V8066292 ([153.39.146.163]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <[e-mail]>; Wed, 12 May 2004 15:53:19 +0000 (GMT)
From: Parantap Lahiri <[e-mail]>
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item
In-reply-to:  <[e-mail]>
To: "'Susan Hares'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, "'Pedro Roque Marques'" <[e-mail]>
Cc: [e-mail]
Message-id: <002501c43839$3e9574d0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook, Build 10.0.4510
Content-type: text/plain; charset=us-ascii
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 12 May 2004 11:53:18 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id MAA01157

Sue,

Setting warning/stop levels on individual prefix might get too hard to
manage. I am fine with global limits as far as the levels go. 

>Do you also want a Disconnect in case
>of /8 and lots of prefix?

Even after filtering the more specifics if the number of prefixes crosses
the global upperbound limit, I think the session should be taken down. 

-Parantap

-----Original Message-----
From: Susan Hares [mailto:[e-mail]] 
Sent: Tuesday, May 11, 2004 7:15 PM
To: Parantap Lahiri; Jeffrey Haas; Pedro Roque Marques
Cc: [e-mail]
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item

Parantap:

So, you want by individual prefix (not
prefix length, not maximum)

1) Warning level
2) Stop level (Ignore further prefix)

Do you also want a Disconnect in case
of /8 and lots of prefix?

My understanding from the information below
is that you want: global limits (0/0 and
anything that refines it) as well as
these local limits.

Is that correct?

Sue 

-----Original Message-----
From: Parantap Lahiri [mailto:[e-mail]]
Sent: Tuesday, May 11, 2004 3:23 PM
To: Jeffrey Haas; 'Pedro Roque Marques'
Cc: [e-mail]
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item


Here is a couple of paragraphs from a mail I dropped to this list some time
back which relates to this discussion ..

Typically though, the SP accepts any prefixes which are more specific to the
ones maintained in the prefix-list filter. The problem arises when the
customer accidentally de-aggregates their prefixes. And when that happens
depending on the block that got de-aggregated, the number of prefixes send
by customer could experience a sudden sizeable jump. In today's world, there
is a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session
would go down permanently if the max-prefix-limit is exceeded. It would take
an urgent operator intervention to bring it up again, of course the operator
would need to make sure the cause has been taken care off before bringing
the session up.

So if we want to use the draft approach to take care of this particular
scenario, a filtering mechanism depending on the specificity of a prefix
could become important. For, e.g., if a session hits the stop level, the
sender could resend all its prefixes after filtering out any prefix more
specific to /24 etc. Of course this specificity should be configurable.
However, if for example, /24 is chosen, it would ensure all the customer
prefixes are still globally routable, but some of their load-balancing
mechanism can get affected. So the price the customer pays for the mishap
gets less harsh.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jeffrey
Haas
Sent: Tuesday, May 11, 2004 2:51 PM
To: Pedro Roque Marques
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item

On Tue, May 11, 2004 at 10:44:49AM -0700, Pedro Roque Marques wrote:
> Does anyone want to venture how this external knowledge would be
> learned or what would it need to consist off ?

[...]

> For instance if this 'external knowledge' is the exact list of
> prefixes to be allowed, then the entire problem of prefix limits makes
> no sense. i.e. prefix-limits themselfs seem to have been designed to
> deal w/ situations where you have incomplete information.

Perhaps.

One specific example I've heard is that a customer gives their
prefixes they wish to provide to their ISP.  The ISP will permit
those and less specifics to be advertised.  They may also permit
a small number of prefixes to be advertised that are not in this
list.  This permits a new customer to be setup downstream of
the limited connection without the need to immediately update the
list.

(Think of the situation where the NOC of the upstream is slow about
updating these lists.  I think in an ideal world, this would be
dealt with using IRR technology but I'll stick to what we have now.)

In the case of a route explosion, prefer the configured prefixes in
the list and let the others drop.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

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


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


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA27927 for <[e-mail]>; Wed, 12 May 2004 12:04:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvVv-0006Ms-Fa; Wed, 12 May 2004 11:19:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNuwq-0000FM-Iq for [e-mail]; Wed, 12 May 2004 10:43:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11075 for <[e-mail]>; Wed, 12 May 2004 10:43:01 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNuwo-0004Eu-6H for [e-mail]; Wed, 12 May 2004 10:43:02 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNuqy-0002Pa-00 for [e-mail]; Wed, 12 May 2004 10:37:02 -0400
Received: from [202.108.35.178] (helo=vip.sina.com) by ietf-mx with smtp (Exim 4.12) id 1BNumF-0000ZA-00 for [e-mail]; Wed, 12 May 2004 10:32:07 -0400
Received: (qmail 12663 invoked from network); 12 May 2004 14:31:33 -0000
Received: from unknown (HELO suntao) (61.48.162.221) by 202.108.35.178 with SMTP; 12 May 2004 14:31:33 -0000
Received: from([e-mail]) to([e-mail])
Message-ID: <004101c4382e$02721ae0$f9affea9@suntao>
From: "sun tao" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MIME_BASE64_LATIN,MIME_BASE64_TEXT autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 12 May 2004 22:32:52 +0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nic.merit.edu id MAA27927

hello!
    >> Yakov Rekhter writes:
> 
> > Those who think that the IDR WG should not take signalled prefix
> > limit as a work item, please speak up now.
    if only the MIB reason,We have the same request for the mib to monitor the ORF event.So I think the ORF way to complete the prefix limit should be include the ORF event mib too.from the  operation complex,I think the draft-keyur-prefixlimit-orf-00.txt is easy to realize and configure.we needn't do other thing than add new orf  type.
                                                                                                                                                                                    best 
                                                                                                                                                                                                            tao
----- Original Message ----- 
From: "Pedro Roque Marques" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, May 11, 2004 1:33 AM
Subject: [Idr] signalled prefix limit as an IDR WG work item


> Yakov Rekhter writes:
> 
> > Those who think that the IDR WG should not take signalled prefix
> > limit as a work item, please speak up now.
> 
> It all depends on what is the expectation. I undertand the fact that
> managing prefix-limits of costumer connections is a significant
> operational problem.
> 
> What is not clear to me is what is the expected service model for this
> after signalled prefix limits are agreed.
> 
> My understanding is that different people have different expectations
> regarding what the mecanism is supposed to acomplish.
> 
> i.e. is the point simply to generate a warning limit in the customer
> syste
> 
> or is the fact that the limit is signaled something that just makes
> life easier to the manager of the customer box ?
> 
> or is it a question of transfer of responsability for the session
> reset ?
> 
> or is the expectation that the routers be inteligent enought to
> understand which prefixes are "good" and should be mainatained and
> which prefixes are "bad" and should be droped.
> 
> The latter is quite hard to define and not simple to implement in a
> fail-proof way.
> 
> I would like to clearly define the problem and expectations before we
> solve it... keep in mind that the more complex the problem definition
> the higher the cost of a solution (and thus less likely to come
> about).
> 
>   Pedro.  
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
> 
> 
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈv¹šŠX§‚X¬´‡kþ'­ú+‚m¦Ïÿÿ0×øžµÿè®æj)fjåŠËbú?


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA25629 for <[e-mail]>; Wed, 12 May 2004 11:42:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvP0-0003XX-FX; Wed, 12 May 2004 11:12:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNuTE-0003Wk-F4 for [e-mail]; Wed, 12 May 2004 10:12:28 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06812; Wed, 12 May 2004 10:12:25 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-multisession-00.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 12 May 2004 10:12:25 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Multisession BGP
	Author(s)	: J. Scudder, C. Appanna
	Filename	: draft-ietf-idr-bgp-multisession-00.txt
	Pages		: 11
	Date		: 2004-5-6
	
This specification augments "Multiprotocol Extensions for BGP-4" [MP-
   BGP] by proposing a mechanism to allow multiple sessions to be used
   between a given pair of BGP speakers.  Each session is used to
   transport routes for one or more AFI/SAFI.  This provides an
   alternative to the current [MP-BGP] approach of multiplexing routes
   for all AFI/SAFI onto a single connection.

   Use of this approach is expected to increase the robustness of the
   BGP protocol as it is used to support more and more diverse AFI/SAFI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-multisession-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ietf-idr-bgp-multisession-00.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-multisession-00.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.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-multisession-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-multisession-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA12180 for <[e-mail]>; Wed, 12 May 2004 09:11:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtO1-0003s4-3F; Wed, 12 May 2004 09:03:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtDW-0002EJ-0O for [e-mail]; Wed, 12 May 2004 08:52:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28937 for <[e-mail]>; Wed, 12 May 2004 08:52:08 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNtDU-0003ue-JB for [e-mail]; Wed, 12 May 2004 08:52:08 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNtCW-0003P8-00 for [e-mail]; Wed, 12 May 2004 08:51:09 -0400
Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BNtBX-0002PX-00 for [e-mail]; Wed, 12 May 2004 08:50:07 -0400
Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4CCajU6020224 for <[e-mail]>; Wed, 12 May 2004 08:49:37 -0400
Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 40A047040005B6A3; Wed, 12 May 2004 08:49:34 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Thread-Index: AcQ2l5kp+ovvWlxRRuy/vb3/bYKjbQBhpbvw
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 12 May 2004 07:49:36 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id JAA12180

> Those who were in favor of accepting 
> draft-chavali-bgp-prefixlimit-01.txt
> as an IDR WG document need to say whether they are in
> favor of accepting draft-chavali-bgp-prefixlimit-02.txt
> as an IDR WG document.

Yes, I support this becoming a WG document.  This is a useful operational mechanism, wherein customers receive a warning on the prefix-limit condition and can take action.  This draft proposes a reasonable approach to address the issue.

Jerry

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA04718 for <[e-mail]>; Wed, 12 May 2004 01:24:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmA1-0007Fc-Ia; Wed, 12 May 2004 01:20:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlq8-0002QU-2k for [e-mail]; Wed, 12 May 2004 00:59:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20551 for <[e-mail]>; Wed, 12 May 2004 00:59:27 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNlq5-0003DK-4u for [e-mail]; Wed, 12 May 2004 00:59:29 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNlp6-0002n0-00 for [e-mail]; Wed, 12 May 2004 00:58:29 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BNlo9-0001xG-00 for [e-mail]; Wed, 12 May 2004 00:57:29 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4C4uh704442; Wed, 12 May 2004 07:56:44 +0300
From: Pekka Savola <[e-mail]>
To: Parantap Lahiri <[e-mail]>
cc: "'Jeffrey Haas'" <[e-mail]>, "'Pedro Roque Marques'" <[e-mail]>, <[e-mail]>
Subject: prefix-limiting scenarios [RE: [Idr] signalled prefix limit as an IDR WG work item]
In-Reply-To: <002a01c4378d$70a9d030$[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 12 May 2004 07:56:43 +0300 (EEST)

Let's try to figure out the scenarios for prefix-limits a bit better..

As to where we use prefix-limits.. toward peers (but not
upstreams/customers).  For customers, we have strict prefix list; for
upstreams, we don't want to filter out anything -- so nothing needed
here.  (We dont allow the customers to advertise more specifics i.e.,
to break the aggregates -- but if you would, prefix-limits could be 
used here as well, as discussed below where I quote Parantap's note.)

For peers, however, this is slightly different.  Generating 
prefix-lists from RIPE DB for our peering sessions would take over 
20,000 lines of access lists.  That's simply unacceptable amount of 
junk to our router configurations.  So, we simply filter based on the 
AS-numbers, and use the prefix limits (the limit is about 5-10 times 
as much as they're advertising now) as a means to disconnect the peer 
if it accidentally starts advertising the whole Internet to us.

We don't need prefix-limit signalling for this kind of stuff at all, 
which is why I said in the first place that I fail to see where it's 
needed but wouldn't object to it being specified as long as it's 
simple.

A few comments about Parantap's scenario below...

On Tue, 11 May 2004, Parantap Lahiri wrote:
> Typically though, the SP accepts any prefixes which are more specific to the
> ones maintained in the prefix-list filter. The problem arises when the
> customer accidentally de-aggregates their prefixes. And when that happens
> depending on the block that got de-aggregated, the number of prefixes send
> by customer could experience a sudden sizeable jump. In today's world, there
> is a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session
> would go down permanently if the max-prefix-limit is exceeded. It would take
> an urgent operator intervention to bring it up again, of course the operator
> would need to make sure the cause has been taken care off before bringing
> the session up.
> 
> So if we want to use the draft approach to take care of this particular
> scenario, a filtering mechanism depending on the specificity of a prefix
> could become important. For, e.g., if a session hits the stop level, the
> sender could resend all its prefixes after filtering out any prefix more
> specific to /24 etc. Of course this specificity should be configurable.
> However, if for example, /24 is chosen, it would ensure all the customer
> prefixes are still globally routable, but some of their load-balancing
> mechanism can get affected. So the price the customer pays for the mishap
> gets less harsh.

I fail to see why you'd need the prefix-length checking here.  
Couldn't you do just:

 1) "what's the normal status i.e., how many prefixes are normal?" 
(e.g., 30)
 2) "decide on the pain threshold, after which you stop receiving more 
prefixes" (e.g., 50)
 3) "decide the punishment threshold, after which you drop the peer"
(e.g., 300)

If the customer ever goes to 2), he has been misbehaving, but the 
existing, less specific prefixes still get through.  If the customer 
happens to reset the session, resulting in some aggregates not getting 
through, you can just add to your instructions that you're using 
prefix-limits and if they want it to get through, they'll have to take 
out those more specifics.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA03241 for <[e-mail]>; Wed, 12 May 2004 01:06:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlof-0002D7-U7; Wed, 12 May 2004 00:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlfk-0000QM-MF for [e-mail]; Wed, 12 May 2004 00:48:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20240 for <[e-mail]>; Wed, 12 May 2004 00:48:44 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNlfh-0006ID-Vu for [e-mail]; Wed, 12 May 2004 00:48:46 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNlee-0005rQ-00 for [e-mail]; Wed, 12 May 2004 00:47:41 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BNleC-0005Q7-00 for [e-mail]; Wed, 12 May 2004 00:47:12 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4C4k0504283; Wed, 12 May 2004 07:46:00 +0300
From: Pekka Savola <[e-mail]>
To: Susan Hares <[e-mail]>
cc: "John G. Scudder" <[e-mail]>, <[e-mail]>
Subject: higher-level of prefix limits [RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 12 May 2004 07:45:59 +0300 (EEST)

On Tue, 11 May 2004, Susan Hares wrote:
> Pekka and John:
> 
> The feature you describe here:
> 
>   >There is another way to specify this as well.  Each router sends the other,
>   >_in advance_, when opening the BGP session, their prefix limits; these
>   >values are stored per peer.  The sending router checks the length of its
>   >adj-ribs-out for the peer whether it exceeds any of these limits, and raises
>   >warnings, stops advertising, etc. as appropriate.  (In that model, no
>   >compliant router ever exceeds these limits, even temporarily.)
> 
> Is in the original draft: It is negotiated at initial OPEN and allowed
> to change while connection (ORF/Dyn-Caps are options).
> 
> So, are you happy with the 3 limits: warning, ignore, disconnect?
> Do you want these limits for all prefixes, a prefix length or
> some specific prefix?

I want the limits to be for all prefixes.  I don't see a real scenario
for anything else.

As I described, there are two things here:

 1) What's being done by the local routers.  They're configured with 
specific kinds of prefix limits.  Current prefix-limits in the 
implementations support at least the local warning, and the local 
reset.

 2) What's being signalled to the foreign routers.  As John described, 
there is *no* use of signalling reset limit to the peer, because reset 
limit is enforced by the local peer.

That leaves us with notifying of warning limit and stop limit only.  
Both could be useful, but I could live with just one as well.  The
preferable spec would be that these are sent when the session is being
opened, and only re-sent if the local administrator changes the
limits.  The foreign peer stores these values, and issues warnings at
their end (using a to-be-defined MIB, for example -- the same
what it does when prefix-limits are configured to warning locally), 
and for the stop limit, restricts the number of prefixes it sents when 
the number exceeds Adj-Ribs-out for the peer.

Again, disconnect limit doesn't need to be signalled, as the local
peer is going to disconnect the remote end based on the locally
configured disconnect limit in any case.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA22172 for <[e-mail]>; Tue, 11 May 2004 22:53:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNjj0-0003gI-TU; Tue, 11 May 2004 22:44:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNjda-0002Q3-6L for [e-mail]; Tue, 11 May 2004 22:38:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14864 for <[e-mail]>; Tue, 11 May 2004 22:38:21 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNjdW-0004sP-QY for [e-mail]; Tue, 11 May 2004 22:38:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNjca-0004Ry-00 for [e-mail]; Tue, 11 May 2004 22:37:25 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BNjbc-0003as-00 for [e-mail]; Tue, 11 May 2004 22:36:24 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4C2ZsBm091201 for <[e-mail]>; Tue, 11 May 2004 19:35:54 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4C2ZsJ15091 for <[e-mail]>; Tue, 11 May 2004 19:35:54 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:35:54 -0700

Folks,

Given the current discussion on the mailing list, the deadline
for comments on accepting draft-chavali-bgp-prefixlimit-02.txt
as an IDR WG document is extended to May 24, 2004.

This way May 24 is the deadline for comments on the following:

1. whether to take signalled prefix limit as a WG item

2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR
   WG document

3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR
   WG document

In your e-mails please clearly indicate your preferences. Providing
rationale for your preferences would be extremely useful as well.

Yakov.

P.S If folks feel that the deadline should be extended beyond
May 24, please say so.

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA21157 for <[e-mail]>; Tue, 11 May 2004 22:42:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNjbE-0001tW-HC; Tue, 11 May 2004 22:36:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNjUx-0000pw-Sw for [e-mail]; Tue, 11 May 2004 22:29:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14481 for <[e-mail]>; Tue, 11 May 2004 22:29:27 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNjUu-0000vY-LW for [e-mail]; Tue, 11 May 2004 22:29:28 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNjTo-0000UK-00 for [e-mail]; Tue, 11 May 2004 22:28:20 -0400
Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BNjSl-0007RU-00 for [e-mail]; Tue, 11 May 2004 22:27:16 -0400
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i4C2Qd5O061250; Tue, 11 May 2004 19:26:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i4C2Qdd4061247; Tue, 11 May 2004 19:26:39 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Susan Hares" <[e-mail]>
Cc: "John G. Scudder" <[e-mail]>, <[e-mail]>
Subject: RE: [Idr] signalled prefix limits -- contrasting approaches
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
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
> be adopted as a working group draft.

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.

> I think there are 3 questions:

> 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. 

> 2) What signalled prefix limits do you want?

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

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.

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA19587 for <[e-mail]>; Tue, 11 May 2004 22:22:57 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNjKm-0007E4-VI; Tue, 11 May 2004 22:19:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNjCT-0006Do-57 for [e-mail]; Tue, 11 May 2004 22:10:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13823 for <[e-mail]>; Tue, 11 May 2004 22:10:21 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNjCQ-0000WZ-3O for [e-mail]; Tue, 11 May 2004 22:10:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNjBV-00006y-00 for [e-mail]; Tue, 11 May 2004 22:09:26 -0400
Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BNjB8-0007UW-00 for [e-mail]; Tue, 11 May 2004 22:09:02 -0400
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i4C28X5O061210; Tue, 11 May 2004 19:08:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i4C28X5O061207; Tue, 11 May 2004 19:08:33 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Tony Li <[e-mail]>
Cc: <[e-mail]>
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:08:33 -0700 (PDT)

Tony Li writes:

> Sue,

> a) As has been pointed out to me privately, my comments below are
> the result of a complete misinterpretation of what's being proposed.
> Please consider my comment withdrawn.

Would you mind sharing ? because i still don't understand what is
being proposed. I understand the part about an integer (or a set)
being passed around... but the actual behavior seems to be undefined. 

I am all for vendor differentiation but i think that for
interoperability reasons one needs to define at least which BGP
speaker (the limiting or limited one) needs to have the external
knowledge necessary to have a session survive when the limited router
is (mis)configured to advertise more prefixes than the limit.
 
> b) I still don't see the point.

If the session does not survive then the added benefit would be at
most an earlier warning to the operator of the side that is
limited. Cease sub-codes already indicate that the limit has been
exceeded and give you the value.

If the point is to have the bgp session survive, then extra
information is required. If that information is already present in the
'limiting' side (e.g. transit provider) one could argue that the limit
does not need to be passed around in bgp.

If on the other hand the extra information is configuration on the
limited side... that does indeed seem to fall into the potential trap
you indicated previously. i.e. trying to protect against misconfig of
the client via more config...

i would argue that the WG should not take this item unless someone can
explain how its going to be used and what advantages does it
bring. But then maybe its is just me that is confused.

  Pedro.

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA17230 for <[e-mail]>; Tue, 11 May 2004 21:54:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNios-0001vt-A4; Tue, 11 May 2004 21:46:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNimR-0001W6-HA for [e-mail]; Tue, 11 May 2004 21:43:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12786 for <[e-mail]>; Tue, 11 May 2004 21:43:28 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNimO-0004HI-ME for [e-mail]; Tue, 11 May 2004 21:43:28 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNilM-0003rc-00 for [e-mail]; Tue, 11 May 2004 21:42:24 -0400
Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1BNikX-00032b-00 for [e-mail]; Tue, 11 May 2004 21:41:33 -0400
Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (sccrmhc13) with SMTP id <200405120141030160002ub5e>; Wed, 12 May 2004 01:41:04 +0000
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: "Parantap Lahiri" <[e-mail]>, "Jeffrey Haas" <[e-mail]>, "Pedro Roque Marques" <[e-mail]>, <[e-mail]>
From: Tony Li <[e-mail]>
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
To: "Susan Hares" <[e-mail]>
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 18:41:02 -0700

Sue,

a) As has been pointed out to me privately, my comments below are the 
result of
a complete misinterpretation of what's being proposed.  Please consider 
my comment
withdrawn.

b) I still don't see the point.

c) My comments represent no one other than myself, an interested 
onlooker.

Tony


On May 11, 2004, at 6:05 PM, Susan Hares wrote:

> Tony:
>
> <working group chair hat on>
>
> Your vote (per John's/Sue's) suggested
> addition of this topic is: NO.
>
> Please confirm.  Also do you at
> this time represent a vendor,
> a service provider or a valued
> researcher/expert? (pick any set
> out of the three)?
>
> <working group chair hat off>
>
> Sue
>
> -----Original Message-----
> From: Tony Li [mailto:[e-mail]]
> Sent: Tuesday, May 11, 2004 8:08 PM
> To: Susan Hares
> Cc: Parantap Lahiri; Jeffrey Haas; Pedro Roque Marques; [e-mail]
> Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
>
>
>
>
> FWIW, I'm having a hard time understanding why we want the prefix limit
> signaled.
>
> I understand the reason to limit the damage that can be caused by a
> peer, but if
> we are concerned about that level of damage, we cannot ignore the
> vulnerability
> that any signaled limit is also bogus, either through maliciousness,
> poor
> implementation, or human error.
>
> In other words, if we're trying to add a sanity check, we need a sanity
> reference
> that isn't provided by the patient.  ;-)
>
> Tony
>


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA14511 for <[e-mail]>; Tue, 11 May 2004 21:21:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNiKt-0004dv-3U; Tue, 11 May 2004 21:15:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNiEV-0003Eu-LY for [e-mail]; Tue, 11 May 2004 21:08:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11481 for <[e-mail]>; Tue, 11 May 2004 21:08:24 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNiET-0004f6-4U for [e-mail]; Tue, 11 May 2004 21:08:25 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNiDZ-0004DP-00 for [e-mail]; Tue, 11 May 2004 21:07:30 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNiCc-0003JL-00 for [e-mail]; Tue, 11 May 2004 21:06:30 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5BBDB2D48F5 for <[e-mail]>; Tue, 11 May 2004 21:06:01 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 45350-01-15 for <[e-mail]>; Tue, 11 May 2004 21:05:48 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 31DF62D48E9 for <[e-mail]>; Tue, 11 May 2004 21:05:48 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] signalled prefix limit as an IDR WG work item
Thread-Index: AcQ3tUD+ROaVKqaaTaKGAuvy48Go/wAB1TyA
From: "Susan Hares" <[e-mail]>
To: "Tony Li" <[e-mail]>
Cc: "Parantap Lahiri" <[e-mail]>, "Jeffrey Haas" <[e-mail]>, "Pedro Roque Marques" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 21:05:48 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id VAA14511

Tony:

<working group chair hat on>

Your vote (per John's/Sue's) suggested
addition of this topic is: NO. 

Please confirm.  Also do you at 
this time represent a vendor,
a service provider or a valued
researcher/expert? (pick any set
out of the three)?

<working group chair hat off> 

Sue

-----Original Message-----
From: Tony Li [mailto:[e-mail]]
Sent: Tuesday, May 11, 2004 8:08 PM
To: Susan Hares
Cc: Parantap Lahiri; Jeffrey Haas; Pedro Roque Marques; [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item




FWIW, I'm having a hard time understanding why we want the prefix limit 
signaled.

I understand the reason to limit the damage that can be caused by a 
peer, but if
we are concerned about that level of damage, we cannot ignore the 
vulnerability
that any signaled limit is also bogus, either through maliciousness, 
poor
implementation, or human error.

In other words, if we're trying to add a sanity check, we need a sanity 
reference
that isn't provided by the patient.  ;-)

Tony


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA13889 for <[e-mail]>; Tue, 11 May 2004 21:14:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNiBC-0001y6-KQ; Tue, 11 May 2004 21:05:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNi4m-000116-1m for [e-mail]; Tue, 11 May 2004 20:58:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11065 for <[e-mail]>; Tue, 11 May 2004 20:58:21 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNi4j-0000B8-Nu for [e-mail]; Tue, 11 May 2004 20:58:21 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNi3v-0007Y1-00 for [e-mail]; Tue, 11 May 2004 20:57:31 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNi31-0006hG-00 for [e-mail]; Tue, 11 May 2004 20:56:35 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3AB6C2D4859 for <[e-mail]>; Tue, 11 May 2004 20:56:06 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 45172-02-5 for <[e-mail]>; Tue, 11 May 2004 20:55:53 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id AAF662D48EE for <[e-mail]>; Tue, 11 May 2004 20:55:53 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] signalled prefix limits -- contrasting approaches
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] signalled prefix limits -- contrasting approaches
Thread-Index: AcQzke2mHj1QGb1KQbOfTnDVYfC3NwEIOZEQ
From: "Susan Hares" <[e-mail]>
To: "John G. Scudder" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 20:55:53 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id VAA13889

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA11398 for <[e-mail]>; Tue, 11 May 2004 20:43:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhXX-0002J5-4j; Tue, 11 May 2004 20:24:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhUz-0001g0-0a for [e-mail]; Tue, 11 May 2004 20:21:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08935 for <[e-mail]>; Tue, 11 May 2004 20:21:22 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNhUw-0006zT-QT for [e-mail]; Tue, 11 May 2004 20:21:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNhU5-0006Z8-00 for [e-mail]; Tue, 11 May 2004 20:20:30 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNhTM-00066e-00 for [e-mail]; Tue, 11 May 2004 20:19:44 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6C2162D487E for <[e-mail]>; Tue, 11 May 2004 20:19:15 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43300-01-47 for <[e-mail]>; Tue, 11 May 2004 20:19:02 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6D52B2D48BF for <[e-mail]>; Tue, 11 May 2004 20:19:02 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] signalled prefix limits -- contrasting approaches 
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] signalled prefix limits -- contrasting approaches 
Thread-Index: AcQzw2R+kAU+6f/wTuS6oVmCqMQgdgD7jHTw
From: "Susan Hares" <[e-mail]>
To: "Enke Chen" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 20:19:02 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id UAA11398

Enke:

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

Please confirm.

Sue

-----Original Message-----
From: Enke Chen [mailto:[e-mail]]
Sent: Thursday, May 06, 2004 7:24 PM
To: [e-mail]
Cc: [e-mail]
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: [e-mail]
> From: "John G. Scudder" <[e-mail]>
> Subject: [Idr] signalled prefix limits -- contrasting approaches
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr


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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA10486 for <[e-mail]>; Tue, 11 May 2004 20:32:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhWX-00029V-1I; Tue, 11 May 2004 20:23:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhLa-0007wZ-2m for [e-mail]; Tue, 11 May 2004 20:11:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08510 for <[e-mail]>; Tue, 11 May 2004 20:11:39 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNhLY-0002dE-19 for [e-mail]; Tue, 11 May 2004 20:11:40 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNhJP-0001n0-00 for [e-mail]; Tue, 11 May 2004 20:09:28 -0400
Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1BNhIl-0001Jb-00 for [e-mail]; Tue, 11 May 2004 20:08:48 -0400
Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (sccrmhc13) with SMTP id <2004051200081401600t6vsce>; Wed, 12 May 2004 00:08:15 +0000
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: "Parantap Lahiri" <[e-mail]>, "Jeffrey Haas" <[e-mail]>, "Pedro Roque Marques" <[e-mail]>, <[e-mail]>
From: Tony Li <[e-mail]>
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
To: "Susan Hares" <[e-mail]>
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 17:08:13 -0700

FWIW, I'm having a hard time understanding why we want the prefix limit 
signaled.

I understand the reason to limit the damage that can be caused by a 
peer, but if
we are concerned about that level of damage, we cannot ignore the 
vulnerability
that any signaled limit is also bogus, either through maliciousness, 
poor
implementation, or human error.

In other words, if we're trying to add a sanity check, we need a sanity 
reference
that isn't provided by the patient.  ;-)

Tony


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA10382 for <[e-mail]>; Tue, 11 May 2004 20:31:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhVa-0001nW-8R; Tue, 11 May 2004 20:22:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhIM-0007Dv-IW for [e-mail]; Tue, 11 May 2004 20:08:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08421 for <[e-mail]>; Tue, 11 May 2004 20:08:20 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNhIK-0001KM-MJ for [e-mail]; Tue, 11 May 2004 20:08:20 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNhHU-0000uM-00 for [e-mail]; Tue, 11 May 2004 20:07:29 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNhH2-0000TM-00 for [e-mail]; Tue, 11 May 2004 20:07:00 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 206822D4903 for <[e-mail]>; Tue, 11 May 2004 20:06:31 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43300-01-30 for <[e-mail]>; Tue, 11 May 2004 20:06:19 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 712AC2D48F4 for <[e-mail]>; Tue, 11 May 2004 20:06:13 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
Thread-Index: AcQz83zGvs6rCPC2SQyTHCub4+NeLQDwOlLA
From: "Susan Hares" <[e-mail]>
To: "Pekka Savola" <[e-mail]>, "John G. Scudder" <[e-mail]>
Cc: "Srikanth Chavali" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 20:06:13 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id UAA10382

Pekka:

The prefix-limits are not re-negotiated without
having an administrative input in either draft.

keyur-prefix draft has only 1 limit per ORF. Hit it
and either ignore, stop receiving or disconnect.
Or try to re-negotiate that one limit. 

If you want to preset multiple limits, choose
that option.  My understanding is that
you choose warn and ignore prefix/stop receiving.

Sue

-----Original Message-----
From: Pekka Savola [mailto:[e-mail]]
Sent: Friday, May 07, 2004 1:12 AM
To: John G. Scudder
Cc: Srikanth Chavali; [e-mail]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]


On Thu, 6 May 2004, John G. Scudder wrote:
> At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
> >2. If warning limit hit send the Dynamic capability (if indicator set).
> >It serves dual purpose as warning and/or renegotiate the capabilites.
> >It gives operators enough time to (debug errors)/(change limits).
> 
> Can you comment as to why warning as a local policy is not sufficient 
> to achieve this end?

I'm not sure if I understand the point 2, above.  (I'm not sure which 
router's "local policy" are you talking about.)

Yes, prefix-limits should not be re-negotiated when a limit has been 
hit.  That's part of the administrative procedures.

Yes, it would also seem ill-advised to send the "you have exceeded 
your prefix limits" -message after the exceeding, as the damage has 
already been done.

Let's assume BGP speaker A advertises prefixes to speaker B, and B has 
set up prefix limits and wishes to inform A about them.

The BGP speaker A must support at least a warning level, and may
support also "code red" level.  That is, when Adj-Ribs-out (for B) on
speaker A reaches the warning level, log a warning message to the
administration of speaker A.  When the advertised prefix count on A
reaches the "code red" level, it needs to log a "code red" message,
and may stop advertising new prefixes.  The stopping part is IMHO not
that important.

On the other hand, Speaker B has set prefix limits to the direction of 
A.  If the advertised prefix count exceed the warning level, a warning 
is logged to the local administration.  If the prefix count exceeds 
the "code red" level, stop accepting new prefixes or reset the 
session and log a "code red" alert.  Note that these have to be done 
always and in any way, because speaker B cannot be sure that speaker A 
is honoring the limits it has sent.  If A honors them, most of these 
errors never get activated.

And just to clarify -- the part about speaker B is already out there 
and requires no notifications at all.  The part people are interested 
of is notifying another BGP speakers of the configured and enforced 
limits, so that the other speakers can log local warning messages or 
prevent the bgp sessions from being reset.

(I don't have have strong opinions on whether it's needed to be able 
to send other limits rather than just the warning.  The warning is 
most important, but the stop might be useful as well.  Reset doesn't 
appear to be necessary at all.)

Hope this clarifies the "scenarios" or "operator requirements" I had 
in mind.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA09487 for <[e-mail]>; Tue, 11 May 2004 20:20:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhG6-0006HE-Nt; Tue, 11 May 2004 20:06:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh3k-0003lQ-AE for [e-mail]; Tue, 11 May 2004 19:53:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07322 for <[e-mail]>; Tue, 11 May 2004 19:53:14 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNh3i-0002Hm-G7 for [e-mail]; Tue, 11 May 2004 19:53:14 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNh2k-0001qk-00 for [e-mail]; Tue, 11 May 2004 19:52:15 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNh1a-00010Y-00 for [e-mail]; Tue, 11 May 2004 19:51:02 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8DCAD2D487D for <[e-mail]>; Tue, 11 May 2004 19:50:33 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43293-01-9 for <[e-mail]>; Tue, 11 May 2004 19:50:20 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 655AA2D48E9 for <[e-mail]>; Tue, 11 May 2004 19:50:20 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
Thread-Index: AcQz1uphUYFtgdzHSEiyUeh1FXUSqAD2rhqA
From: "Susan Hares" <[e-mail]>
To: "Keyur Patel" <[e-mail]>, "Srikanth Chavali" <[e-mail]>
Cc: "idr" <[e-mail]>, "John G. Scudder" <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:50:20 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id UAA09487

Keyur:

I think I've sent this a few times:

 My understanding from Mo and Luyuan,
 and other service providers are:

	a)Warning levels - let them get time
				 to fix the problems,

	b) Ignore prefix levels - limits memory
	c) Disconnect - prevents full routing
			    table sending.

Just how does the reset prefix limit provide this?

The purpose of negotiated policy instead of "local
policy (Aka configuiration)" is that it is exchanged
in BGP, saved in the MIB, and re-negotiated upon the
fly.

So, mechanisms aside.  I really think that the reset
limit is not sufficient for this purposes.

If you can accomplish this action with one, please
let me know.  All I see that you are falling back
to non-negotiation on the part of these limits.
Saying "check the config".  

Well statistics from research institutions
(yankee group, etc) give 30% to 50% of network 
outages are based on configuration
errors.  I guess it made sense if the service providers
want to include a few more things in negotiated,
tracked parameters.

Sue 

-----Original Message-----
From: Keyur Patel [mailto:[e-mail]]
Sent: Thursday, May 06, 2004 9:53 PM
To: Srikanth Chavali
Cc: idr; John G. Scudder
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]


Also, can you comment on as to why the "reset prefix limit" as a part of 
local policy is not sufficient (considering this *may* be taken into 
consideration when prefix limits have already been reached)? Resetting 
the session is just one of the possible local actions that can be taken 
(when the prefix limit is reached). Why just enumerate one of them in 
the draft?

-Keyur

John G. Scudder wrote:

> Srikanth,
>
> At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>
>> 2. If warning limit hit send the Dynamic capability (if indicator set).
>> It serves dual purpose as warning and/or renegotiate the capabilites.
>> It gives operators enough time to (debug errors)/(change limits).
>
>
> Can you comment as to why warning as a local policy is not sufficient 
> to achieve this end?
>
> In particular it would be great if you could address the observation 
> that whether generated locally or remotely, the warning is liable to 
> be a function of the Adj-RIB size (which is known by both peers) and 
> the prefix-limit value (which is likewise known to both peers). 
> Furthermore the action of the router to bring the warning to the 
> attention of the operator is inherently going to be a local matter.
>
> Thanks,
>
> --John
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>



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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA08057 for <[e-mail]>; Tue, 11 May 2004 20:03:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh1f-0003BV-Aw; Tue, 11 May 2004 19:51:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgy0-000234-23 for [e-mail]; Tue, 11 May 2004 19:47:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06987 for <[e-mail]>; Tue, 11 May 2004 19:47:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgxy-0007TQ-7i for [e-mail]; Tue, 11 May 2004 19:47:18 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgx2-00073I-00 for [e-mail]; Tue, 11 May 2004 19:46:20 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BNgwC-0006Dw-00 for [e-mail]; Tue, 11 May 2004 19:45:28 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 May 2004 15:50:56 +0000
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4BNiuC1023197; Tue, 11 May 2004 16:44:56 -0700 (PDT)
Received: from [192.168.42.3] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA11039; Tue, 11 May 2004 19:44:54 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p06020449bcc71345f18c@[192.168.42.3]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
To: "Susan Hares" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt
Cc: "Mo Miri" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:45:16 -0400

At 6:24 PM -0400 5/11/04, Susan Hares wrote:
>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.

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.

>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?

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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA07745 for <[e-mail]>; Tue, 11 May 2004 19:59:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh1c-00036f-Bv; Tue, 11 May 2004 19:51:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgrE-00019D-7O for [e-mail]; Tue, 11 May 2004 19:40:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06792 for <[e-mail]>; Tue, 11 May 2004 19:40:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgrC-0004UY-H4 for [e-mail]; Tue, 11 May 2004 19:40:18 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgqJ-00044Z-00 for [e-mail]; Tue, 11 May 2004 19:39:23 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNgpL-0003DP-00 for [e-mail]; Tue, 11 May 2004 19:38:23 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E80DF2D48C2 for <[e-mail]>; Tue, 11 May 2004 19:37:53 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42924-01-13 for <[e-mail]>; Tue, 11 May 2004 19:37:40 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A22A02D4868 for <[e-mail]>; Tue, 11 May 2004 19:37:40 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Thread-Index: AcQzkfTSCN2LiYP3RomrQs10Z5+QMQEHrL8A
From: "Susan Hares" <[e-mail]>
To: "John G. Scudder" <[e-mail]>, "Pekka Savola" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:37:40 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id TAA07745

Pekka and John:

The feature you describe here:

  >There is another way to specify this as well.  Each router sends the other,
  >_in advance_, when opening the BGP session, their prefix limits; these
  >values are stored per peer.  The sending router checks the length of its
  >adj-ribs-out for the peer whether it exceeds any of these limits, and raises
  >warnings, stops advertising, etc. as appropriate.  (In that model, no
  >compliant router ever exceeds these limits, even temporarily.)

Is in the original draft: It is negotiated at initial OPEN and allowed
to change while connection (ORF/Dyn-Caps are options).

So, are you happy with the 3 limits: warning, ignore, disconnect?
Do you want these limits for all prefixes, a prefix length or
some specific prefix?

Sue

-----Original Message-----
From: John G. Scudder [mailto:[e-mail]]
Sent: Thursday, May 06, 2004 1:00 PM
To: Pekka Savola
Cc: [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document


At 3:04 PM +0300 5/5/04, Pekka Savola wrote:
...
>A high-level comment:
>---------------------
>
>The model seems to be so that when the receiving BGP speaker receives the
>number of routes which exceed a warning, stop or reset limit, it sends a
>message to inform the other router about exceeding this limit, raising a
>warning, askit it to stop, or reset the session.
>
>There is another way to specify this as well.  Each router sends the other,
>_in advance_, when opening the BGP session, their prefix limits; these
>values are stored per peer.  The sending router checks the length of its
>adj-ribs-out for the peer whether it exceeds any of these limits, and raises
>warnings, stops advertising, etc. as appropriate.  (In that model, no
>compliant router ever exceeds these limits, even temporarily.)

Note that this is exactly what we've proposed in 
draft-keyur-prefixlimit-orf-00.txt.

>The main difference here appears to be that the currently specified model
>requires the receiving BGP speaker to react _after_ the incident.  I.e., if
>the neighbor accidentally advertises the whole internet (instead of e.g.,
>100 prefixes), the damage has already been done, and most probably, the BGP
>session has already been reset, because the receiving BGP speaker has
>to have prefix-limits in place in any case to ensure that neighbors
>will honour the limits.
>
>So, IMHO that would argue for notifying the router about your limits in
>advance.. and if the other router does not honor them, raise and alarm, shut
>down the session, etc. on your own if needed.
>
>If you buy the latter model, the error code 5 appears to be unnecessary.
>
>(Both models allow changing the limit on the fly with dynamic capabilities,
>I think.)

Yes.

Regards,

--John

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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA07706 for <[e-mail]>; Tue, 11 May 2004 19:59:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh1a-00035B-TR; Tue, 11 May 2004 19:51:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgoj-0000g7-FA for [e-mail]; Tue, 11 May 2004 19:37:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06674 for <[e-mail]>; Tue, 11 May 2004 19:37:43 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgoh-0003Cx-Pw for [e-mail]; Tue, 11 May 2004 19:37:43 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgns-0002k4-00 for [e-mail]; Tue, 11 May 2004 19:36:52 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNgmz-0002Af-00 for [e-mail]; Tue, 11 May 2004 19:35:57 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 635812D48C2 for <[e-mail]>; Tue, 11 May 2004 19:35:28 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42924-01-6 for <[e-mail]>; Tue, 11 May 2004 19:35:15 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 65BC22D484F for <[e-mail]>; Tue, 11 May 2004 19:35:15 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG  document
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG  document
Thread-Index: AcQzsv+C73tr6dTKQbqHopTMrfAtcQD/Xr9Q
From: "Susan Hares" <[e-mail]>
To: "John G. Scudder" <[e-mail]>, <[e-mail]>
Cc: "Pekka Savola" <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:35:15 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id TAA07706

John:

The question is two-fold

1) How many limits
	(warn, ignore/stop, disconnect)

2) What mechanisms.

It would be good to separate the
discussions into these two parts.

I hope my flurry of email has tried
to focus on this point.

Sue

-----Original Message-----
From: John G. Scudder [mailto:[e-mail]]
Sent: Thursday, May 06, 2004 5:20 PM
To: [e-mail]
Cc: Pekka Savola
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document


At 12:59 PM -0400 5/6/04, John G. Scudder wrote:
>At 3:04 PM +0300 5/5/04, Pekka Savola wrote:
...
>>(Both models allow changing the limit on the fly with dynamic capabilities,
>>I think.)
>
>Yes.

To clarify, what we propose in draft-keyur-prefixlimit-orf-00.txt 
allows changing the limit on the fly but uses ORFs rather than 
dynamic capabilities.

--John

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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA07616 for <[e-mail]>; Tue, 11 May 2004 19:57:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh0c-0002t0-DB; Tue, 11 May 2004 19:50:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgoG-0000VE-Pv for [e-mail]; Tue, 11 May 2004 19:37:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06577 for <[e-mail]>; Tue, 11 May 2004 19:37:15 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgoF-00039R-35 for [e-mail]; Tue, 11 May 2004 19:37:15 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgn3-0002FW-00 for [e-mail]; Tue, 11 May 2004 19:36:02 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNglz-0001eB-00 for [e-mail]; Tue, 11 May 2004 19:34:55 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C8D2F2D487E for <[e-mail]>; Tue, 11 May 2004 19:34:25 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42923-01-9 for <[e-mail]>; Tue, 11 May 2004 19:34:11 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7A3A52D484F for <[e-mail]>; Tue, 11 May 2004 19:34:11 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
Thread-Index: AcQzz8R8xfR5E1DJS3KKzSkfW+eCawD4H5fQ
From: "Susan Hares" <[e-mail]>
To: "John G. Scudder" <[e-mail]>, "Srikanth Chavali" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:34:10 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id TAA07616

Local warning is meant aid engendering of
some NOC action.  If the NOC action
is to up the limit, "re-negotiation"
will make sure both sides keep the current
limits.

Yes -- it's about making sure both sides
have this answer.  I doubt they will 
share configuration file information. 

Sue

-----Original Message-----
From: John G. Scudder [mailto:[e-mail]]
Sent: Thursday, May 06, 2004 8:56 PM
To: Srikanth Chavali
Cc: [e-mail]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]


Srikanth,

At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>2. If warning limit hit send the Dynamic capability (if indicator set).
>It serves dual purpose as warning and/or renegotiate the capabilites.
>It gives operators enough time to (debug errors)/(change limits).

Can you comment as to why warning as a local policy is not sufficient 
to achieve this end?

In particular it would be great if you could address the observation 
that whether generated locally or remotely, the warning is liable to 
be a function of the Adj-RIB size (which is known by both peers) and 
the prefix-limit value (which is likewise known to both peers). 
Furthermore the action of the router to bring the warning to the 
attention of the operator is inherently going to be a local matter.

Thanks,

--John

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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA07498 for <[e-mail]>; Tue, 11 May 2004 19:56:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgzd-0002Xy-Rj; Tue, 11 May 2004 19:49:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgmn-0008Nn-Mz for [e-mail]; Tue, 11 May 2004 19:35:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06338 for <[e-mail]>; Tue, 11 May 2004 19:35:43 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgmm-0002D0-2d for [e-mail]; Tue, 11 May 2004 19:35:44 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNglW-0001eS-00 for [e-mail]; Tue, 11 May 2004 19:34:27 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNgkO-0000jl-00 for [e-mail]; Tue, 11 May 2004 19:33:16 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C7B122D4898 for <[e-mail]>; Tue, 11 May 2004 19:32:46 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42308-01-24 for <[e-mail]>; Tue, 11 May 2004 19:32:33 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 733EA2D4868 for <[e-mail]>; Tue, 11 May 2004 19:32:33 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
Thread-Index: AcQz3/OYSbw1JpmkSTedC259mRiIgADz7Dkg
From: "Susan Hares" <[e-mail]>
To: "John G. Scudder" <[e-mail]>, "Srikanth Chavali" <[e-mail]>
Cc: "Keyur Patel" <[e-mail]>, "idr" <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:32:33 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id TAA07498

John:

The warnings are remotely signaled
so that both sides of BGP connection know the limits.

The warnings are sent to a local SNMP or
your friendly Cisco CLI stations. At that point,
our friends at the super-noc would contact
customer, determine fix, sit down change
configs to have BGP re-negotiate (ORF/Dyn-Cap)
mechanisms on the fly.

Both BGP get to agree on the new amount
and go on.  

I think you understood this.. but I wanted
to make sure we are in alignment on the problem.

Sue

-----Original Message-----
From: John G. Scudder [mailto:[e-mail]]
Sent: Thursday, May 06, 2004 10:55 PM
To: Srikanth Chavali
Cc: Keyur Patel; idr
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]


Srikanth,

Yes, I read -00 back around the Minneapolis meeting.  Is there a 
specific section of the document you believe addresses the questions? 
Since you refer to "service providers perspective" I went and reread 
section 2.2 of -00 ("Current Service Provider Perspective") and it 
doesn't appear to answer either question.

Note that I don't need to be convinced of the value of issuing 
warnings.  Rather, I'm questioning if they need to be remotely 
signalled.

Regards,

--John

At 9:59 PM -0400 5/6/04, Srikanth Chavali wrote:
>Keyur/John,
>                  Did you guys had a chance to read 00.txt vesion of 
>this draft? We had incorporated the views of the Service Providers 
>and the discussions we had with them there. If you did'nt let me 
>know i will either point you to that or send you a copy of it.  That 
>should answer your questions as well as the service providers 
>perspective on that.  In the latest versions we had trimmed that 
>text for simplicity sake.
>
>srikanth chavali
>
>Keyur Patel wrote:
>
>>Also, can you comment on as to why the "reset prefix limit" as a 
>>part of local policy is not sufficient (considering this *may* be 
>>taken into consideration when prefix limits have already been 
>>reached)? Resetting the session is just one of the possible local 
>>actions that can be taken (when the prefix limit is reached). Why 
>>just enumerate one of them in the draft?
>>
>>-Keyur
>>
>>John G. Scudder wrote:
>>
>>>Srikanth,
>>>
>>>At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>>>
>>>>2. If warning limit hit send the Dynamic capability (if indicator set).
>>>>It serves dual purpose as warning and/or renegotiate the capabilites.
>>>>It gives operators enough time to (debug errors)/(change limits).
>>>
>>>
>>>
>>>Can you comment as to why warning as a local policy is not 
>>>sufficient to achieve this end?
>>>
>>>In particular it would be great if you could address the 
>>>observation that whether generated locally or remotely, the 
>>>warning is liable to be a function of the Adj-RIB size (which is 
>>>known by both peers) and the prefix-limit value (which is likewise 
>>>known to both peers). Furthermore the action of the router to 
>>>bring the warning to the attention of the operator is inherently 
>>>going to be a local matter.
>>>
>>>Thanks,
>>>
>>>--John

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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA06901 for <[e-mail]>; Tue, 11 May 2004 19:48:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgo1-0000Lt-80; Tue, 11 May 2004 19:37:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNghg-00071W-8h for [e-mail]; Tue, 11 May 2004 19:30:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06100 for <[e-mail]>; Tue, 11 May 2004 19:30:26 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNghe-0007eS-OG for [e-mail]; Tue, 11 May 2004 19:30:26 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNggd-0007DM-00 for [e-mail]; Tue, 11 May 2004 19:29:24 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNgg1-0006lE-00 for [e-mail]; Tue, 11 May 2004 19:28:45 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7D59C2D4898 for <[e-mail]>; Tue, 11 May 2004 19:28:15 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 41305-01-77 for <[e-mail]>; Tue, 11 May 2004 19:28:01 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 42D022D484F for <[e-mail]>; Tue, 11 May 2004 19:28:01 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
Thread-Index: AcQ0QX6NZ+59SxpNRZ+n+hEVKdcvSwDbZk3Q
From: "Susan Hares" <[e-mail]>
To: "John G. Scudder" <[e-mail]>, "Pekka Savola" <[e-mail]>
Cc: "Srikanth Chavali" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:28:01 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id TAA06901

John:

The purpose is not to "nag" A, but
to negotiate limits after a warning
has be hit.  Supposedly:

	Warn - We get 1 week to talk
		 to customer and reset the limit

		The ISP resolves this limit with
		the customer and resets the warning
		limit, the stop limit to something higher.
		
		Disconnect limit may/may not hit this.
	(Dynamic capabilities/ ORF can reset
	  while the BGP connection is running)

So, in your description below.. I don't see
how 1 limit and a lot of assumptions gives
the same clear negotiation and tracking of ORF
information.

Sue


-----Original Message-----
From: John G. Scudder [mailto:[e-mail]]
Sent: Friday, May 07, 2004 9:43 AM
To: Pekka Savola
Cc: Srikanth Chavali; [e-mail]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]


At 8:12 AM +0300 5/7/04, Pekka Savola wrote:
>On Thu, 6 May 2004, John G. Scudder wrote:
>>  At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>>  >2. If warning limit hit send the Dynamic capability (if indicator set).
>>  >It serves dual purpose as warning and/or renegotiate the capabilites.
>>  >It gives operators enough time to (debug errors)/(change limits).
>>
>>  Can you comment as to why warning as a local policy is not sufficient
>>  to achieve this end?
>
>I'm not sure if I understand the point 2, above.

Just to be sure we all understand each other, point 2 above is 
Srikanth, the question below it which refers to local policy it is 
me.  Multiple quote levels can get confusing.

>(I'm not sure which router's "local policy" are you talking about.)

I was referring to the (warning generation) policy on Speaker A in 
your example quoted below.  The text that you omitted from your quote 
elaborates on the question, but my point is that A can and should 
generate the warning on its own, B doesn't need to signal A telling 
it when to generate a warning.  It's sufficient for B to tell A ahead 
of time what the maximum limit is, and rely on A to notice when it's 
approaching it.

In other words, I think we're agreeing on this point -- at any rate I 
agree with the way you've written out the scenario in your example. 
What I do NOT think is needed is if the example were instead to say:

"When the Adj-RIB-In on B (from A) reaches the warning level, B sends 
A a message requesting that A log a warning message to its 
administration."

which is what I understand draft-chavali to propose.  I don't think B 
needs to nag A -- A already knows how many routes it has sent as 
you've shown in your example.

>Yes, prefix-limits should not be re-negotiated when a limit has been
>hit.  That's part of the administrative procedures.
>
>Yes, it would also seem ill-advised to send the "you have exceeded
>your prefix limits" -message after the exceeding, as the damage has
>already been done.
>
>Let's assume BGP speaker A advertises prefixes to speaker B, and B has
>set up prefix limits and wishes to inform A about them.
>
>The BGP speaker A must support at least a warning level, and may
>support also "code red" level.  That is, when Adj-Ribs-out (for B) on
>speaker A reaches the warning level, log a warning message to the
>administration of speaker A.  When the advertised prefix count on A
>reaches the "code red" level, it needs to log a "code red" message,
>and may stop advertising new prefixes.  The stopping part is IMHO not
>that important.
[snip]

Regards,

--John

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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA06837 for <[e-mail]>; Tue, 11 May 2004 19:48:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgm6-0008Cy-I2; Tue, 11 May 2004 19:35:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgdi-0006E2-Hg for [e-mail]; Tue, 11 May 2004 19:26:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05972 for <[e-mail]>; Tue, 11 May 2004 19:26:20 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgdg-0005ub-Tx for [e-mail]; Tue, 11 May 2004 19:26:21 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgcf-0005Uc-00 for [e-mail]; Tue, 11 May 2004 19:25:18 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNgc2-0004wj-00 for [e-mail]; Tue, 11 May 2004 19:24:38 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9DF3E2D4876 for <[e-mail]>; Tue, 11 May 2004 19:24:09 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42622-01-3 for <[e-mail]>; Tue, 11 May 2004 19:23:55 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5125D2D4854 for <[e-mail]>; Tue, 11 May 2004 19:23:55 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
Thread-Index: AcQ0iUeyEJsWEouKRreHqRUG2u+ulgDJRm0w
From: "Susan Hares" <[e-mail]>
To: "John G. Scudder" <[e-mail]>, "Fang, Luyuan, ALABS" <[e-mail]>
Cc: "Srikanth Chavali" <[e-mail]>, "Keyur Patel" <[e-mail]>, "idr" <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:23:55 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id TAA06837

John:

The warning is there in your draft as well
on both sides.  So, I'm a bit confused.
You indicate you should give information to
local SNMP information.  The negotiation
comes between the customer and the provider. 
Both should get warnings. 

Perhaps we need to go back to the 3 scenarios.

1) Warn me at a limit X (to local input)
2) Ignore prefixes at limit Y
3) Disconnect the boxes at limit Z 

I think they want 3 limits for these
three things.  Can you tell me how your
specification would do this? 

Sue



-----Original Message-----
From: John G. Scudder [mailto:[e-mail]]
Sent: Friday, May 07, 2004 7:06 PM
To: Fang, Luyuan, ALABS
Cc: Srikanth Chavali; Keyur Patel; idr
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]


Luyuan,

I certainly don't mean to question that there is operational goodness 
from having warnings emitted by customer boxes.  In fact, I agree.

Rather, my point is that the warning doesn't need to be sent by the 
provider side box to the customer side box.  Since the provider box 
would tell the customer box the prefix limit ahead of time, and since 
the customer box knows the size of its own Adj-RIB-Out towards the 
provider box, the customer box can and should generate the warning 
locally.

The effect would be the same, the difference being that one approach 
requires extra messaging and one doesn't.  In either case, the 
customer receives a warning when the limit is reached.

Note that no matter what, some aspect of the warning is beyond the 
provider box's control -- even if we went with a solution where the 
provider box transmits a warning to the customer box, the customer 
box still has to properly present that warning to the customer as a 
log message, SNMP trap, or whatnot.  So, regardless of whether 
warnings are generated locally or remotely, it's inescapable that the 
customer box controls whether and how the warning is delivered. 
Given that, why would we want to go to the effort of generating them 
remotely instead of getting the same benefit for lower cost by doing 
it locally?

Thanks,

--John

At 5:44 PM -0500 5/7/04, Fang, Luyuan, ALABS wrote:
>This warning mechanism is useful from the perspective of operations. 
>With the external messages it ensures that the customers receive the 
>warning on the limit reached condition and take immediate actions, 
>rather than for the service providers  manually calling up the 
>customers.
>
>This might not be applied to all the BGP peers but to some of the 
>peers that we deem fit for it.
>
>Since it can be turned off, it should limit the impact from the 
>processing standpoint. Of course, if this consumes fair amount of 
>resources of the boxes, we need to take that into consideration.
>
>Luyuan Fang
>[e-mail]
>
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On Behalf Of John G.
>Scudder
>Sent: Thursday, May 06, 2004 10:55 PM
>To: Srikanth Chavali
>Cc: Keyur Patel; idr
>Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
>IDR WG document]
>
>
>Srikanth,
>
>Yes, I read -00 back around the Minneapolis meeting.  Is there a
>specific section of the document you believe addresses the questions?
>Since you refer to "service providers perspective" I went and reread
>section 2.2 of -00 ("Current Service Provider Perspective") and it
>doesn't appear to answer either question.
>
>Note that I don't need to be convinced of the value of issuing
>warnings.  Rather, I'm questioning if they need to be remotely
>signalled.
>
>Regards,
>
>--John
>
>At 9:59 PM -0400 5/6/04, Srikanth Chavali wrote:
>>Keyur/John,
>>                   Did you guys had a chance to read 00.txt vesion of
>>this draft? We had incorporated the views of the Service Providers
>>and the discussions we had with them there. If you did'nt let me
>>know i will either point you to that or send you a copy of it.  That
>>should answer your questions as well as the service providers
>>perspective on that.  In the latest versions we had trimmed that
>>text for simplicity sake.
>>
>>srikanth chavali
>>
>>Keyur Patel wrote:
>>
>>>Also, can you comment on as to why the "reset prefix limit" as a
>>>part of local policy is not sufficient (considering this *may* be
>>>taken into consideration when prefix limits have already been
>>>reached)? Resetting the session is just one of the possible local
>>>actions that can be taken (when the prefix limit is reached). Why
>>>just enumerate one of them in the draft?
>>>
>>>-Keyur
>>>
>>>John G. Scudder wrote:
>>>
>>>>Srikanth,
>>>>
>>>>At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>>>>
>>>>>2. If warning limit hit send the Dynamic capability (if indicator set).
>  >>>>It serves dual purpose as warning and/or renegotiate the capabilites.
>>>>>It gives operators enough time to (debug errors)/(change limits).
>>>>
>>>>
>>>>
>>>>Can you comment as to why warning as a local policy is not
>>>>sufficient to achieve this end?
>>>>
>>>>In particular it would be great if you could address the
>>>>observation that whether generated locally or remotely, the
>>>>warning is liable to be a function of the Adj-RIB size (which is
>>>>known by both peers) and the prefix-limit value (which is likewise
>>>>known to both peers). Furthermore the action of the router to
>>>>bring the warning to the attention of the operator is inherently
>>>>going to be a local matter.
>>>>
>>>>Thanks,
>>>>
>>>>--John
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr


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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA05671 for <[e-mail]>; Tue, 11 May 2004 19:33:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgbb-000678-11; Tue, 11 May 2004 19:24:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgUx-0004bA-EO for [e-mail]; Tue, 11 May 2004 19:17:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05754 for <[e-mail]>; Tue, 11 May 2004 19:17:17 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgUv-000265-Vn for [e-mail]; Tue, 11 May 2004 19:17:17 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgTy-0001g3-00 for [e-mail]; Tue, 11 May 2004 19:16:18 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNgSx-0000on-00 for [e-mail]; Tue, 11 May 2004 19:15:15 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A42DD2D4898 for <[e-mail]>; Tue, 11 May 2004 19:14:45 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42122-01-16 for <[e-mail]>; Tue, 11 May 2004 19:14:32 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4E7ED2D48C2 for <[e-mail]>; Tue, 11 May 2004 19:14:32 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] signalled prefix limit as an IDR WG work item
Thread-Index: AcQ3kSa6N5vFJkkDQPest9iEzOycrAAHB+gg
From: "Susan Hares" <[e-mail]>
To: "Parantap Lahiri" <[e-mail]>, "Jeffrey Haas" <[e-mail]>, "Pedro Roque Marques" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 19:14:32 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id TAA05671

Parantap:

So, you want by individual prefix (not
prefix length, not maximum)

1) Warning level
2) Stop level (Ignore further prefix)

Do you also want a Disconnect in case
of /8 and lots of prefix?

My understanding from the information below
is that you want: global limits (0/0 and
anything that refines it) as well as
these local limits.

Is that correct?

Sue 

-----Original Message-----
From: Parantap Lahiri [mailto:[e-mail]]
Sent: Tuesday, May 11, 2004 3:23 PM
To: Jeffrey Haas; 'Pedro Roque Marques'
Cc: [e-mail]
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item


Here is a couple of paragraphs from a mail I dropped to this list some time
back which relates to this discussion ..

Typically though, the SP accepts any prefixes which are more specific to the
ones maintained in the prefix-list filter. The problem arises when the
customer accidentally de-aggregates their prefixes. And when that happens
depending on the block that got de-aggregated, the number of prefixes send
by customer could experience a sudden sizeable jump. In today's world, there
is a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session
would go down permanently if the max-prefix-limit is exceeded. It would take
an urgent operator intervention to bring it up again, of course the operator
would need to make sure the cause has been taken care off before bringing
the session up.

So if we want to use the draft approach to take care of this particular
scenario, a filtering mechanism depending on the specificity of a prefix
could become important. For, e.g., if a session hits the stop level, the
sender could resend all its prefixes after filtering out any prefix more
specific to /24 etc. Of course this specificity should be configurable.
However, if for example, /24 is chosen, it would ensure all the customer
prefixes are still globally routable, but some of their load-balancing
mechanism can get affected. So the price the customer pays for the mishap
gets less harsh.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jeffrey
Haas
Sent: Tuesday, May 11, 2004 2:51 PM
To: Pedro Roque Marques
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item

On Tue, May 11, 2004 at 10:44:49AM -0700, Pedro Roque Marques wrote:
> Does anyone want to venture how this external knowledge would be
> learned or what would it need to consist off ?

[...]

> For instance if this 'external knowledge' is the exact list of
> prefixes to be allowed, then the entire problem of prefix limits makes
> no sense. i.e. prefix-limits themselfs seem to have been designed to
> deal w/ situations where you have incomplete information.

Perhaps.

One specific example I've heard is that a customer gives their
prefixes they wish to provide to their ISP.  The ISP will permit
those and less specifics to be advertised.  They may also permit
a small number of prefixes to be advertised that are not in this
list.  This permits a new customer to be setup downstream of
the limited connection without the need to immediately update the
list.

(Think of the situation where the NOC of the upstream is slow about
updating these lists.  I think in an ideal world, this would be
dealt with using IRR technology but I'll stick to what we have now.)

In the case of a route explosion, prefer the configured prefixes in
the list and let the others drop.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

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


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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA01106 for <[e-mail]>; Tue, 11 May 2004 18:37:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNfkK-00036G-Dm; Tue, 11 May 2004 18:29:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNfhd-0002IH-Ho for [e-mail]; Tue, 11 May 2004 18:26:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02404 for <[e-mail]>; Tue, 11 May 2004 18:26:16 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNfha-0002Y0-Oc for [e-mail]; Tue, 11 May 2004 18:26:18 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNfgl-00027N-00 for [e-mail]; Tue, 11 May 2004 18:25:27 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNfgB-0001d1-00 for [e-mail]; Tue, 11 May 2004 18:24:51 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 780132D48FA for <[e-mail]>; Tue, 11 May 2004 18:24:14 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39794-02-45 for <[e-mail]>; Tue, 11 May 2004 18:24:01 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3A8AE2D484F for <[e-mail]>; Tue, 11 May 2004 18:24:01 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-02.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-chavali-bgp-prefixlimit-02.txt
Thread-Index: AcQ24XgG+xCua37VQ/6VfrplP2wPLgAo3v5g
From: "Susan Hares" <[e-mail]>
To: "John G. Scudder" <[e-mail]>, "Mo Miri" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 18:24:01 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id SAA01106

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:[e-mail]]
Sent: Monday, May 10, 2004 6:28 PM
To: Mo Miri
Cc: [e-mail]
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26155 for <[e-mail]>; Tue, 11 May 2004 17:34:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNeQ2-00045Y-9m; Tue, 11 May 2004 17:04:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNeJO-0001xm-2l for [e-mail]; Tue, 11 May 2004 16:57:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24815 for <[e-mail]>; Tue, 11 May 2004 16:57:10 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNeJM-0001jO-0p for [e-mail]; Tue, 11 May 2004 16:57:12 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNeIY-0001J9-00 for [e-mail]; Tue, 11 May 2004 16:56:23 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BNeHP-0000sU-00 for [e-mail]; Tue, 11 May 2004 16:55:11 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4BKqkaL041459; Tue, 11 May 2004 16:52:46 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Sandy Murphy <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] change in draft-ietf-idr-bgp-vuln-00.txt 
In-reply-to: Your message of "Tue, 11 May 2004 16:21:57 EDT." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 16:52:46 -0400

In message <[e-mail]>, Sandy Murphy writes:
> >A cease is a very temporary DoS.  In order to be effective the attack
> >must be somewhat continuous.  Injection of bad routing is a
> >semipermanent DoS which if successful would be hard to detect.
> >Therefore the latter is far more dangerous.  Knowing that we are much
> >more safe against the dangerous form of attack is significant and
> >should be mentioned, unless the goal is just to bash BGP.
> 
> Curtis, are you saying that you think the draft should be amended to
> discuss this attack?  (Which would mean not just a request to the RFC
> Editor, but a new version, last call, etc.)


Its not worth upsetting the last call.  Please change it when/if you
make another iteration of the draft.

Thanks,

Curtis


> Presently, section 2 (Attacks) of the draft says:
> 
>      message insertion: BGP does not provide protection against
>      insertion of messages.  However, because BGP uses TCP, when the
>      connection is fully established, message insertion by an outsider
>      would require accurate sequence number prediction (not entirely out
>      of the question, but more difficult with mature TCP
>      implementations) or session stealing attacks.
> 
>      message deletion: BGP does not provide protection against deletion
>      of messages.  Again, more difficult against a mature TCP
>      implementation but not entirely out of the question
> 
>      message modification: BGP does not provide protection against
>      modification of messages.  A modification that did not change the
>      length of the TCP payload would in general not be detectable.
> 
> In section 3.1.1 "Message Header", it says:
> 
> Event 21: Each BGP message starts with a standard header.  In all cases,
> syntactic errors in the message header will cause the BGP speaker to
> close the connection, release all associated BGP resources, delete all
> routes learned through that connection and run its decision process to
> decide on new routes.
> 
> 
> If you do not think these are sufficient, given the tcpm-tcpsecure
> draft discussion of blind data injection, then would something like
> the following be what you would want to see?
> 
> 3.2.  Vulnerabilities through Other Protocols
> 
> 3.2.1.  TCP messages
> ...
> 3.2.1.1.  TCP SYN
> 3.2.1.2.  TCP SYN ACK
> 3.2.1.3.  TCP ACK
> 3.2.1.4.  TCP RST/FIN/FIN-ACK
> 
> add a new section:
> 
> 3.2.1.5.  TCP Data Injection
> 
> A TCP segment is accepted if some of its sequence numbers fall within
> the receive window.  If the sequence numbers do not match the left
> edge of the window, then the segment may, in some implementations, be
> queued for later processing.  There is a chance that this would allow
> insertion of bogus data that would be delivered to BGP.  However,
> later arriving in-order segments may partially or completely overwrite
> the out-of-order segment.  In order for this feature to be used to
> attack BGP, the attacker would not only have to predict a sequence
> number lying in the receive window, but also be fortunate in the bogus
> segment not being overwritten by later arriving authentic segments.
> Furthermore, the BGP message header contains framing information
> (length, etc.) that would make it difficult for any bogus inserted
> data that did get delivered to BGP to pass the syntactic checks.  The
> likely result would be a Message Header Error, causing the connection
> to be closed, rather than acceptance of bogus routing information.  The
> use of [5] will counter this attack.
> 
> (That's off the top of my head, but you get the idea.)
> 
> --Sandy

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA23304 for <[e-mail]>; Tue, 11 May 2004 17:01:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe4w-00087K-KQ; Tue, 11 May 2004 16:42:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe0H-0005v7-BM for [e-mail]; Tue, 11 May 2004 16:37:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23524 for <[e-mail]>; Tue, 11 May 2004 16:37:13 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNe03-0000Zj-5D for [e-mail]; Tue, 11 May 2004 16:37:15 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNdyw-00004B-00 for [e-mail]; Tue, 11 May 2004 16:36:07 -0400
Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BNdxu-0007Io-00 for [e-mail]; Tue, 11 May 2004 16:35:02 -0400
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4BKVrma020500 for <[e-mail]>; Tue, 11 May 2004 16:31:54 -0400 (EDT)
Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAveaG4N; Tue, 11 May 04 16:31:20 -0400
Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4BKLvQ4000895; Tue, 11 May 2004 16:21:57 -0400 (EDT)
From: Sandy Murphy <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [Idr] change in draft-ietf-idr-bgp-vuln-00.txt
Cc: [e-mail], [e-mail]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 16:21:57 -0400 (EDT)

>A cease is a very temporary DoS.  In order to be effective the attack
>must be somewhat continuous.  Injection of bad routing is a
>semipermanent DoS which if successful would be hard to detect.
>Therefore the latter is far more dangerous.  Knowing that we are much
>more safe against the dangerous form of attack is significant and
>should be mentioned, unless the goal is just to bash BGP.

Curtis, are you saying that you think the draft should be amended to
discuss this attack?  (Which would mean not just a request to the RFC
Editor, but a new version, last call, etc.)

Presently, section 2 (Attacks) of the draft says:

     message insertion: BGP does not provide protection against
     insertion of messages.  However, because BGP uses TCP, when the
     connection is fully established, message insertion by an outsider
     would require accurate sequence number prediction (not entirely out
     of the question, but more difficult with mature TCP
     implementations) or session stealing attacks.

     message deletion: BGP does not provide protection against deletion
     of messages.  Again, more difficult against a mature TCP
     implementation but not entirely out of the question

     message modification: BGP does not provide protection against
     modification of messages.  A modification that did not change the
     length of the TCP payload would in general not be detectable.

In section 3.1.1 "Message Header", it says:

Event 21: Each BGP message starts with a standard header.  In all cases,
syntactic errors in the message header will cause the BGP speaker to
close the connection, release all associated BGP resources, delete all
routes learned through that connection and run its decision process to
decide on new routes.


If you do not think these are sufficient, given the tcpm-tcpsecure
draft discussion of blind data injection, then would something like
the following be what you would want to see?

3.2.  Vulnerabilities through Other Protocols

3.2.1.  TCP messages
...
3.2.1.1.  TCP SYN
3.2.1.2.  TCP SYN ACK
3.2.1.3.  TCP ACK
3.2.1.4.  TCP RST/FIN/FIN-ACK

add a new section:

3.2.1.5.  TCP Data Injection

A TCP segment is accepted if some of its sequence numbers fall within
the receive window.  If the sequence numbers do not match the left
edge of the window, then the segment may, in some implementations, be
queued for later processing.  There is a chance that this would allow
insertion of bogus data that would be delivered to BGP.  However,
later arriving in-order segments may partially or completely overwrite
the out-of-order segment.  In order for this feature to be used to
attack BGP, the attacker would not only have to predict a sequence
number lying in the receive window, but also be fortunate in the bogus
segment not being overwritten by later arriving authentic segments.
Furthermore, the BGP message header contains framing information
(length, etc.) that would make it difficult for any bogus inserted
data that did get delivered to BGP to pass the syntactic checks.  The
likely result would be a Message Header Error, causing the connection
to be closed, rather than acceptance of bogus routing information.  The
use of [5] will counter this attack.

(That's off the top of my head, but you get the idea.)

--Sandy

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA23152 for <[e-mail]>; Tue, 11 May 2004 17:00:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe4h-0007p5-Rl; Tue, 11 May 2004 16:42:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNdsY-0003Bh-NR for [e-mail]; Tue, 11 May 2004 16:29:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22947 for <[e-mail]>; Tue, 11 May 2004 16:29:27 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNdsW-0004ir-Rn for [e-mail]; Tue, 11 May 2004 16:29:28 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNdrS-0004Ef-00 for [e-mail]; Tue, 11 May 2004 16:28:23 -0400
Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BNdqa-0003n9-00 for [e-mail]; Tue, 11 May 2004 16:27:28 -0400
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4BKOab4019227 for <[e-mail]>; Tue, 11 May 2004 16:24:36 -0400 (EDT)
Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5DaazL; Tue, 11 May 04 16:24:00 -0400
Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4BKO1mk000973; Tue, 11 May 2004 16:24:01 -0400 (EDT)
From: Sandy Murphy <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [Idr] change in draft-ietf-idr-bgp-vuln-00.txt
Cc: [e-mail], [e-mail]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 16:24:01 -0400 (EDT)

>BGP security discussion is not off topic therefore if TCP issues
>impact BGP security its not off topic.

I didn't mean to suggest that the discussion of TCP issues was
off-topic, just that the discussion of TCP implementation issues
was probably too specific for this venue.  The -vuln draft does
spend some space talking about TCP issues.

--Sandy

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA17396 for <[e-mail]>; Tue, 11 May 2004 15:49:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNd5g-0000ME-Uv; Tue, 11 May 2004 15:39:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNctC-0005Vc-Sg for [e-mail]; Tue, 11 May 2004 15:26:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19479 for <[e-mail]>; Tue, 11 May 2004 15:26:04 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNctB-0000dm-Ie for [e-mail]; Tue, 11 May 2004 15:26:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNcsI-0000BC-00 for [e-mail]; Tue, 11 May 2004 15:25:10 -0400
Received: from pmesmtp02.wcom.com ([199.249.20.2] helo=pmesmtp02.mci.com) by ietf-mx with esmtp (Exim 4.12) id 1BNcrG-00075x-00 for [e-mail]; Tue, 11 May 2004 15:24:06 -0400
Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <[e-mail]> for [e-mail]; Tue, 11 May 2004 19:23:36 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <[e-mail]>; Tue, 11 May 2004 19:23:36 +0000 (GMT)
Received: from WS344V8066292 ([153.39.146.163]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <[e-mail]>; Tue, 11 May 2004 19:23:28 +0000 (GMT)
From: Parantap Lahiri <[e-mail]>
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item
In-reply-to: <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "'Pedro Roque Marques'" <[e-mail]>
Cc: [e-mail]
Message-id: <002a01c4378d$70a9d030$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook, Build 10.0.4510
Content-type: text/plain; charset=us-ascii
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 15:23:29 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA17396

Here is a couple of paragraphs from a mail I dropped to this list some time
back which relates to this discussion ..

Typically though, the SP accepts any prefixes which are more specific to the
ones maintained in the prefix-list filter. The problem arises when the
customer accidentally de-aggregates their prefixes. And when that happens
depending on the block that got de-aggregated, the number of prefixes send
by customer could experience a sudden sizeable jump. In today's world, there
is a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session
would go down permanently if the max-prefix-limit is exceeded. It would take
an urgent operator intervention to bring it up again, of course the operator
would need to make sure the cause has been taken care off before bringing
the session up.

So if we want to use the draft approach to take care of this particular
scenario, a filtering mechanism depending on the specificity of a prefix
could become important. For, e.g., if a session hits the stop level, the
sender could resend all its prefixes after filtering out any prefix more
specific to /24 etc. Of course this specificity should be configurable.
However, if for example, /24 is chosen, it would ensure all the customer
prefixes are still globally routable, but some of their load-balancing
mechanism can get affected. So the price the customer pays for the mishap
gets less harsh.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jeffrey
Haas
Sent: Tuesday, May 11, 2004 2:51 PM
To: Pedro Roque Marques
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item

On Tue, May 11, 2004 at 10:44:49AM -0700, Pedro Roque Marques wrote:
> Does anyone want to venture how this external knowledge would be
> learned or what would it need to consist off ?

[...]

> For instance if this 'external knowledge' is the exact list of
> prefixes to be allowed, then the entire problem of prefix limits makes
> no sense. i.e. prefix-limits themselfs seem to have been designed to
> deal w/ situations where you have incomplete information.

Perhaps.

One specific example I've heard is that a customer gives their
prefixes they wish to provide to their ISP.  The ISP will permit
those and less specifics to be advertised.  They may also permit
a small number of prefixes to be advertised that are not in this
list.  This permits a new customer to be setup downstream of
the limited connection without the need to immediately update the
list.

(Think of the situation where the NOC of the upstream is slow about
updating these lists.  I think in an ideal world, this would be
dealt with using IRR technology but I'll stick to what we have now.)

In the case of a route explosion, prefer the configured prefixes in
the list and let the others drop.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

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


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA15638 for <[e-mail]>; Tue, 11 May 2004 15:28:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNcnJ-0004GB-T1; Tue, 11 May 2004 15:20:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNcdn-0006wa-9e for [e-mail]; Tue, 11 May 2004 15:10:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17639 for <[e-mail]>; Tue, 11 May 2004 15:10:07 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNcdk-0001CA-AB for [e-mail]; Tue, 11 May 2004 15:10:08 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNccs-0000lr-00 for [e-mail]; Tue, 11 May 2004 15:09:15 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BNcc4-0000LZ-00 for [e-mail]; Tue, 11 May 2004 15:08:25 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4BJ5vaL040921; Tue, 11 May 2004 15:05:57 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Sandy Murphy <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] change in draft-ietf-idr-bgp-vuln-00.txt 
In-reply-to: Your message of "Tue, 11 May 2004 13:11:37 EDT." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 15:05:57 -0400

In message <[e-mail]>, Sandy Murphy writes:
> > If
> >insertion of bogus data is the attacker's goal a packet boundary must
> >be matched and the insertion must match a packet boundary or a cease
> >will be caused and the bogus insertion lost.
> 
> Yes, I've been wondering about the "blind data injection" part
> of the tcpm-tcpsecure draft.  First, not all TCP implementations buffer
> out-of-order packets.  Second, unless the segment's bytes exactly
> match a later arriving segment's upper boundary, then some of the
> out-of-order segment's bytes could be overwritten.  But isn't this also
> implementation specific?

BGP message have to be aligned.  If they are not aligned a cease
occurs.  If a cease occurs all information is refreshed so the
attacker did not successfully inject anything.

> And then comes the problem, as you say, of trying to match up the
> BGP framing.  If the bogus data does get delivered to the application
> (BGP) (depending on the timing of the reads and the arrival of the
> real data), then not parsing as a proper BGP packet could cause a
> CEASE.  Which would be yet another way to bring down a connection,
> presuming that you needed another ;-}.

A cease is a very temporary DoS.  In order to be effective the attack
must be somewhat continuous.  Injection of bad routing is a
semipermanent DoS which if successful would be hard to detect.
Therefore the latter is far more dangerous.  Knowing that we are much
more safe against the dangerous form of attack is significant and
should be mentioned, unless the goal is just to bash BGP.

> But the TCP issues, particularly implementation specific, are probably
> off-topic for this list.
> 
> --Sandy

BGP security discussion is not off topic therefore if TCP issues
impact BGP security its not off topic.

Curtis

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA14677 for <[e-mail]>; Tue, 11 May 2004 15:16:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNcXs-0003OB-Ai; Tue, 11 May 2004 15:04:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNcSC-0006dT-Go for [e-mail]; Tue, 11 May 2004 14:58:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16411 for <[e-mail]>; Tue, 11 May 2004 14:58:08 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNcS9-0003mV-Jz for [e-mail]; Tue, 11 May 2004 14:58:09 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNcRE-0003Mz-00 for [e-mail]; Tue, 11 May 2004 14:57:13 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNcQP-0002Zx-00 for [e-mail]; Tue, 11 May 2004 14:56:21 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7812E2D4876 for <[e-mail]>; Tue, 11 May 2004 14:55:51 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 34218-01-17 for <[e-mail]>; Tue, 11 May 2004 14:55:38 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 1B7C02D4812 for <[e-mail]>; Tue, 11 May 2004 14:55:38 -0400 (EDT)
content-class: urn:content-classes:message
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
Thread-Topic: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
Thread-Index: AcQz1P4gjeviFVSoSny8v3oevIUSrgDsEi/A
From: "Susan Hares" <[e-mail]>
To: "Chandrashekhar Appanna" <[e-mail]>, "Srikanth Chavali" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 14:55:37 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA14677

Chandra: 

The next paragraph in dynamic capabilities (after
the one you quoted says: 

   "This document defines a new BGP capability termed "Dynamic
   Capability", which would allow the dynamic update of capabilities
   over an established BGP session. This capability would facilitate
   non-disruptive capability changes by BGP speakers."

The maximum prefix negotiation is to allow
changing of these limits in a non-disruptive fashion.

The providers set a warning, a ignore limit (stop taking
more prefixes), and a disconnect.

As an example, it can help the providers
solve these problems 

Problem 1: Want to limit a AFI/SAFI to a certain 
		maximum limit of prefixes

Problem 2: Want to allow a "warning" threshold before
		the limit so I can re-negotiate with the
		providers.  The providers want this large
		enough so they can spend 1 week or 2 weeks
		tracking down the problem.  That way it's not
		an emergency.

Problem 3: Providers want to immediately disconnect those
		people who erroneously send a full routing table
		dump via such a BGP client.

(By the way, apparently misconfiguration causes problem
 number 3 alot. Ringing a large bell for problem 3 helps
 remove other problems.)

So, the dynamic capabilities - Like the ability to handle
AFI/SAFI pairs allows re-negotiation of these limits
without dropping the configuration.

John Scudder/Enke Chen have sent two types of comments:

  1) Not all 3 limits are needed (warning, ignore, disconnect)
  2) ORF are simplier than Dynamic capabilities to 
	implement these features 

For comment 1: 3 limits, I think the co-authors on our
draft (Luyuan Faung (AT&T) and Mo Miri) started us down
this path to be able to get the limits.  They want to
get this in a non-disruptive manner. 

So, that's why I think the Dynamic capabilities fit
just right to fix this problem.  

Sue

PS - I know I've not responded to comment 2. 

     That's an interesting technical discussion,
     that we'll take up in a different email messages.
	
	Both have pro's and con's.  As we indicated in 
	draft-chavali-bgp-prefixlimit-01, we think both
	ORFs and Dynamic capabilities can work together
	or separately.  I promise more on that in a momemnt.

-----Original Message-----
From: Chandrashekhar Appanna [mailto:[e-mail]]
Sent: Thursday, May 06, 2004 9:36 PM
To: Srikanth Chavali
Cc: [e-mail]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]



  Dynamic capability is not intended as a signalling mechanism of
  state - that is how I see it. It is mainly to exchange high level
  session capabilities.  I would rather use a different mechanism that 
  is for the purpose of such exchanging dynamic state changes.

  To quote from the DYN-CAP draft :

   -------------
   Currently BGP capabilities [BGP-CAP] are only advertised in the OPEN
   message during the session initialization. In order to enable a new
   capability or remove an existing capability (such as an Address
   Family support [BGP-MP]), an established session may need to be
   reset, which would disrupt other services running over the session.
   -------------

  I would like to understand why the authors think that dynamic
  capabilites is an appropriate medium for this purpose.

  thanks,
  Chandra Appanna.



On Thu, May 06, 2004 at 08:23:16PM -0400, Srikanth Chavali wrote:
> I am forwarding my response to Pekka's email to clarify things..
> 
> srikanth chavali
> 
> -------- Original Message --------
> Subject: 	Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG 
> document
> Date: 	Wed, 05 May 2004 10:37:02 -0400
> From: 	Srikanth Chavali <[e-mail]>
> To: 	Pekka Savola <[e-mail]>, [e-mail]
> References: 	<[e-mail]>
> 
> 
> 
> Hi Pekka,
>              Thanks for your comments. I have replied to your model 
> related comments:
> 
> Pekka Savola wrote:
> 
> >A high-level comment:
> >---------------------
> >
> >The model seems to be so that when the receiving BGP speaker receives the
> >number of routes which exceed a warning, stop or reset limit, it sends a
> >message to inform the other router about exceeding this limit, raising a
> >warning, askit it to stop, or reset the session.
> >
> The draft does'nt say/mean/intend this.
> 
> >
> >There is another way to specify this as well.  Each router sends the 
> >other,
> >_in advance_, when opening the BGP session, their prefix limits; these
> >values are stored per peer.  The sending router checks the length of its
> >adj-ribs-out for the peer whether it exceeds any of these limits, and 
> >raises
> >warnings, stops advertising, etc. as appropriate.  (In that model, no 
> >compliant router ever exceeds these limits, even temporarily.)
> >
> The above is what the draft specifies. Please note that the exchange of 
> the prefix limit capability in the OPEN
> message (Not the Dynamic capability) achieves what you're saying above. 
> This is already specified in the draft.
> 
> So here's the mechanism in short:
> 
> 1. Exchange the capability in OPEN message. The BGP speakers note them 
> and are expected to honor them.
> 2. If warning limit hit send the Dynamic capability (if indicator set). 
> It serves dual purpose as warning and/or renegotiate the capabilites.
> It gives operators enough time to (debug errors)/(change limits).
> 3. If stop limit hit stop route advertisements. Again send Dynamic 
> capability whose purpose is as mentioned in 2.
> 
> We're working on revising the text for clarity, but if there's anything 
> specific in the text which caused mis-interpretation please
> let us know and we will address it.
> 
> Thanks
> 
> srikanth chavali
> 
> 
> 

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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13980 for <[e-mail]>; Tue, 11 May 2004 15:08:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNcWt-0002lc-2e; Tue, 11 May 2004 15:03:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNcNM-0005uY-W6 for [e-mail]; Tue, 11 May 2004 14:53:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16194 for <[e-mail]>; Tue, 11 May 2004 14:53:09 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNcNK-0001dn-7B for [e-mail]; Tue, 11 May 2004 14:53:10 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNcMM-0001EL-00 for [e-mail]; Tue, 11 May 2004 14:52:11 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNcLr-0000mo-00 for [e-mail]; Tue, 11 May 2004 14:51:39 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 77AA42D488E; Tue, 11 May 2004 14:51:04 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 33935-02-17; Tue, 11 May 2004 14:50:53 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 198B62D484A; Tue, 11 May 2004 14:50:53 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i4BIor718902; Tue, 11 May 2004 14:50:53 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p0602041bbcc557c423c0@[192.168.42.3]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, May 11, 2004 at 10:44:49AM -0700
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 14:50:53 -0400

On Tue, May 11, 2004 at 10:44:49AM -0700, Pedro Roque Marques wrote:
> Does anyone want to venture how this external knowledge would be
> learned or what would it need to consist off ?

[...]

> For instance if this 'external knowledge' is the exact list of
> prefixes to be allowed, then the entire problem of prefix limits makes
> no sense. i.e. prefix-limits themselfs seem to have been designed to
> deal w/ situations where you have incomplete information.

Perhaps.

One specific example I've heard is that a customer gives their
prefixes they wish to provide to their ISP.  The ISP will permit
those and less specifics to be advertised.  They may also permit
a small number of prefixes to be advertised that are not in this
list.  This permits a new customer to be setup downstream of
the limited connection without the need to immediately update the
list.

(Think of the situation where the NOC of the upstream is slow about
updating these lists.  I think in an ideal world, this would be
dealt with using IRR technology but I'll stick to what we have now.)

In the case of a route explosion, prefer the configured prefixes in
the list and let the others drop.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA12016 for <[e-mail]>; Tue, 11 May 2004 14:44:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNc2x-0000zv-3r; Tue, 11 May 2004 14:32:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbwF-0007UP-Mz for [e-mail]; Tue, 11 May 2004 14:25:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13928 for <[e-mail]>; Tue, 11 May 2004 14:25:08 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNbwD-0004n6-2K for [e-mail]; Tue, 11 May 2004 14:25:09 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNbvM-0004Mg-00 for [e-mail]; Tue, 11 May 2004 14:24:16 -0400
Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BNbub-0003wA-00 for [e-mail]; Tue, 11 May 2004 14:23:29 -0400
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4BIKbfA028827 for <[e-mail]>; Tue, 11 May 2004 14:20:37 -0400 (EDT)
Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5iaGa4; Tue, 11 May 04 14:20:08 -0400
Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4BHBbaU020625; Tue, 11 May 2004 13:11:37 -0400 (EDT)
From: Sandy Murphy <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [Idr] change in draft-ietf-idr-bgp-vuln-00.txt
Cc: [e-mail], [e-mail]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 13:11:37 -0400 (EDT)

> If
>insertion of bogus data is the attacker's goal a packet boundary must
>be matched and the insertion must match a packet boundary or a cease
>will be caused and the bogus insertion lost.

Yes, I've been wondering about the "blind data injection" part
of the tcpm-tcpsecure draft.  First, not all TCP implementations buffer
out-of-order packets.  Second, unless the segment's bytes exactly
match a later arriving segment's upper boundary, then some of the
out-of-order segment's bytes could be overwritten.  But isn't this also
implementation specific?

And then comes the problem, as you say, of trying to match up the
BGP framing.  If the bogus data does get delivered to the application
(BGP) (depending on the timing of the reads and the arrival of the
real data), then not parsing as a proper BGP packet could cause a
CEASE.  Which would be yet another way to bring down a connection,
presuming that you needed another ;-}.

But the TCP issues, particularly implementation specific, are probably
off-topic for this list.

--Sandy

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08667 for <[e-mail]>; Tue, 11 May 2004 14:03:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbU5-0001f8-48; Tue, 11 May 2004 13:56:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbMV-0008Qz-5d for [e-mail]; Tue, 11 May 2004 13:48:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11758 for <[e-mail]>; Tue, 11 May 2004 13:48:12 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNbMS-0004WD-UO for [e-mail]; Tue, 11 May 2004 13:48:13 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNbLe-00044z-00 for [e-mail]; Tue, 11 May 2004 13:47:22 -0400
Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BNbKm-0003a5-00 for [e-mail]; Tue, 11 May 2004 13:46:28 -0400
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i4BHin5O060127; Tue, 11 May 2004 10:44:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i4BHinsX060124; Tue, 11 May 2004 10:44:49 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Jeffrey Haas <[e-mail]>
Cc: "John G. Scudder" <[e-mail]>, [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p0602041bbcc557c423c0@[192.168.42.3]> <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 10:44:49 -0700 (PDT)

Jeffrey Haas writes:

> In some cases, dropping excess prefixes - especially with some
> external knowledge as to which are more preferable than others - is
> less disruptive.  In absence of that external knowledge, dropping
> the peering session produces the least surprising results.

I'm in strong agreement w. you specially when it comes to the last phrase.

Does anyone want to venture how this external knowledge would be
learned or what would it need to consist off ?

It may turn out that this external knowledge has a cost that its
higher than what is admissible.

For instance if this 'external knowledge' is the exact list of
prefixes to be allowed, then the entire problem of prefix limits makes
no sense. i.e. prefix-limits themselfs seem to have been designed to
deal w/ situations where you have incomplete information.

I would suggest that we need to think this through before we can
answer Yakovs question regarding should this be a WG item or not.

  Pedro.

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA02056 for <[e-mail]>; Tue, 11 May 2004 12:42:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNa7u-0007C1-9u; Tue, 11 May 2004 12:29:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNZyH-0004en-Vx for [e-mail]; Tue, 11 May 2004 12:19:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06014 for <[e-mail]>; Tue, 11 May 2004 12:19:06 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNZyG-0004hZ-JA for [e-mail]; Tue, 11 May 2004 12:19:08 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNZxL-0004HC-00 for [e-mail]; Tue, 11 May 2004 12:18:11 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BNZwS-0003pt-00 for [e-mail]; Tue, 11 May 2004 12:17:17 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i4BGEjaL039959; Tue, 11 May 2004 12:14:46 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
cc: [e-mail], Sandy Murphy <[e-mail]>
Reply-To: [e-mail]
Subject: Re: [Idr] change in draft-ietf-idr-bgp-vuln-00.txt 
In-reply-to: Your message of "Tue, 11 May 2004 06:26:34 PDT." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 12:14:45 -0400

In message <[e-mail]>, Yakov Rekhter writes
:
> Folks,
> 
> Sandy Murphy, the author of draft-ietf-idr-bgp-vuln-00.txt, proposed
> the following change to her document, Replace 
>   
>   Spoofing a RST in this situation requires an attacker to guess a sequence 
>   number that is in the proper half of the sending window,
> 
> with
> 
>   Spoofing a RST in this situation requires an attacker to guess a sequence 
>   number that need only be within the receive window [9],
> 
> and add a [9] reference to the Paul Watson talk about the TCP RST
> study he did.
> 
> The proposed change is intended to make the issue with TCP RST more
> clear and accurate.
> 
> If there are any objections to the proposed change, please
> send them to the list by May 18, 2004.
> 
> Yakov.



Yakov,

Very good change.  It makes the statement much more clear and reminds
us that the probability is based on the number space divided by the
window size (minus the size of the attacker's payload).  If DoS is the
goal then all that is needed is a single byte to cause a cease.  If
insertion of bogus data is the attacker's goal a packet boundary must
be matched and the insertion must match a packet boundary or a cease
will be caused and the bogus insertion lost.  Might be worth
mentioning that too (optional).

Curtis


ps - ah that's easy to fix just make the window real small like a
couple of bytes... [just kidding of course :) ]

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA25878 for <[e-mail]>; Tue, 11 May 2004 11:19:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYtP-0007f1-8b; Tue, 11 May 2004 11:10:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYip-0005Qu-VX for [e-mail]; Tue, 11 May 2004 10:59:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01707 for <[e-mail]>; Tue, 11 May 2004 10:59:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNYin-0001sz-CG for [e-mail]; Tue, 11 May 2004 10:59:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNYhA-00019h-00 for [e-mail]; Tue, 11 May 2004 10:57:24 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BNYfb-0000C9-00 for [e-mail]; Tue, 11 May 2004 10:55:48 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 11 May 2004 07:55:14 -0700
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4BEtFC1022164; Tue, 11 May 2004 07:55:15 -0700 (PDT)
Received: from [192.168.42.3] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA14034; Tue, 11 May 2004 10:55:12 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p0602042fbcc695de5a53@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p0602041bbcc557c423c0@[192.168.42.3]> <[e-mail]>
To: Jeffrey Haas <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 10:53:37 -0400

At 10:18 AM -0400 5/11/04, Jeffrey Haas wrote:
>On Mon, May 10, 2004 at 01:31:18PM -0400, John G. Scudder wrote:
...
>  > If you drop prefixes, there's a real risk that the party whose
>>  prefixes are dropped won't notice until later, potentially quite a
>>  bit later.
>
>This presumes that there is no signalling mechanism to let this party
>know that their prefixes are being dropped.

Agreed.

>  > I think that if we were so foolish as to adopt a spec that tried to
>>  exclude one approach or the other, we'd just end up with nonstandard
>>  vendor-specific knobs anyway, since some folks will prefer one
>>  approach, some the other.
>
>I believe this argues for having "drop prefixes" and "drop the session"
>both be in our proposed solution.

Wholeheartedly agreed.

--John

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA25754 for <[e-mail]>; Tue, 11 May 2004 11:18:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYle-0005nA-PN; Tue, 11 May 2004 11:02:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYhX-00054L-0i for [e-mail]; Tue, 11 May 2004 10:57:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01571 for <[e-mail]>; Tue, 11 May 2004 10:57:42 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNYhU-0001D8-4i for [e-mail]; Tue, 11 May 2004 10:57:44 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNYfx-0000ea-00 for [e-mail]; Tue, 11 May 2004 10:56:10 -0400
Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BNYeV-0007YS-00 for [e-mail]; Tue, 11 May 2004 10:54:39 -0400
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4BEpMJx023704 for <[e-mail]>; Tue, 11 May 2004 10:51:22 -0400 (EDT)
Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAkhaqeU; Tue, 11 May 04 10:50:14 -0400
Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4BDubaX009890; Tue, 11 May 2004 09:56:37 -0400 (EDT)
From: Sandy Murphy <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Idr] Re: change in  draft-ietf-idr-bgp-vuln-00.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 09:56:37 -0400 (EDT)

>Sandy Murphy, the author of draft-ietf-idr-bgp-vuln-00.txt, proposed
>the following change to her document, Replace 
>
>  Spoofing a RST in this situation requires an attacker to guess a sequence 
>  number that is in the proper half of the sending window,
>
>with
>
>  Spoofing a RST in this situation requires an attacker to guess a sequence 
>  number that need only be within the receive window [9],
>

Note: this returns the discussion of TCP RST to the language that
was used in the draft for half a dozen prior versions of the draft.  So the
working group should be very familiar with this language - you've seen
this *many times* before.

>The proposed change is intended to make the issue with TCP RST more
>clear and accurate.

And to help those who have seen the recent discussions of TCP RST and
are looking for coverage of the issue in the draft - the old language
matches the public reports better.

--Sandy

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA23588 for <[e-mail]>; Tue, 11 May 2004 10:41:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYCo-0005su-Jk; Tue, 11 May 2004 10:26:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNY8I-0004ev-Ba for [e-mail]; Tue, 11 May 2004 10:21:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28799 for <[e-mail]>; Tue, 11 May 2004 10:21:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNY8G-0001ho-5c for [e-mail]; Tue, 11 May 2004 10:21:20 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNY7D-0001Gl-00 for [e-mail]; Tue, 11 May 2004 10:20:16 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNY6N-0000nb-00 for [e-mail]; Tue, 11 May 2004 10:19:23 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id ABF4C2D4876; Tue, 11 May 2004 10:18:52 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25005-01-44; Tue, 11 May 2004 10:18:40 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EBEA72D48E9; Tue, 11 May 2004 10:18:39 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i4BEIdl18404; Tue, 11 May 2004 10:18:39 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: "John G. Scudder" <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p0602041bbcc557c423c0@[192.168.42.3]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p0602041bbcc557c423c0@[192.168.42.3]>; from [e-mail] on Mon, May 10, 2004 at 01:31:18PM -0400
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 10:18:39 -0400

On Mon, May 10, 2004 at 01:31:18PM -0400, John G. Scudder wrote:
> You think so?  I'm not so sure.  Dropping routes on the floor can be 
> substantially harder to debug.  Consider the differences in the 
> failure modes --
> 
> If you drop the session, both parties know right away that something 
> is broken.  There will be immediate attention to the problem while 
> the cause is still evident.

And yet many people think that this is the wrong tool or at least too
harsh of one.

Our end goal, IMO, is survivability of the provider network in
instances where resources (prefixes learned from a peer) are
limited.  In all cases, we wish to limit this or at least we do
for the point of this discussion.

Dropping the session serves this purpose.

In some cases, dropping excess prefixes - especially with some external
knowledge as to which are more preferable than others - is less
disruptive.  In absence of that external knowledge, dropping the
peering session produces the least surprising results.

> If you drop prefixes, there's a real risk that the party whose 
> prefixes are dropped won't notice until later, potentially quite a 
> bit later.

This presumes that there is no signalling mechanism to let this party
know that their prefixes are being dropped.

> I think that if we were so foolish as to adopt a spec that tried to 
> exclude one approach or the other, we'd just end up with nonstandard 
> vendor-specific knobs anyway, since some folks will prefer one 
> approach, some the other.

I believe this argues for having "drop prefixes" and "drop the session"
both be in our proposed solution.

> --John

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA23037 for <[e-mail]>; Tue, 11 May 2004 10:32:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNY9x-0005IM-6C; Tue, 11 May 2004 10:23:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNY4D-0001qs-2q for [e-mail]; Tue, 11 May 2004 10:17:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28380 for <[e-mail]>; Tue, 11 May 2004 10:17:05 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNY4A-0007m4-T3 for [e-mail]; Tue, 11 May 2004 10:17:06 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNY36-0007N1-00 for [e-mail]; Tue, 11 May 2004 10:16:01 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BNY2d-0006xz-00 for [e-mail]; Tue, 11 May 2004 10:15:31 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4BEF0Bm088753 for <[e-mail]>; Tue, 11 May 2004 07:15:00 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4BEF0J23007 for <[e-mail]>; Tue, 11 May 2004 07:15:00 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: [Idr] Soft-Notify as an IDR WG document
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 07:15:00 -0700

Folks,

The draft didn't generate enough support to justify its acceptance
as an IDR WG document.

Sue & Yakov.

------- Forwarded Message

Date:    Mon, 26 Apr 2004 08:01:36 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
Subject: [Idr] Soft-Notify as an IDR WG document

Folks,

Please comment on the attached. The deadline for comments is
May 10.

Yakov.

- ------- Forwarded Message

Date:    Tue, 20 Apr 2004 12:47:27 -0700
From:    Gargi Nalawade <[e-mail]>
To:      [e-mail]
Subject: [Idr] Soft-Notify as IDR WG document

Hi All,

I would like to request that BGP Soft-Notify draft,
draft-nalawade-bgp-soft-notify-00.txt be accepted as
an IDR WG document.

- - -Gargi


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

- ------- End of Forwarded Message


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

------- End of Forwarded Message


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA19660 for <[e-mail]>; Tue, 11 May 2004 09:43:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXPT-0005PV-RQ; Tue, 11 May 2004 09:35:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXLV-0004aV-Gj for [e-mail]; Tue, 11 May 2004 09:30:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25428 for <[e-mail]>; Tue, 11 May 2004 09:30:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNXLT-0005B3-NZ for [e-mail]; Tue, 11 May 2004 09:30:55 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNXKc-0004nY-00 for [e-mail]; Tue, 11 May 2004 09:30:02 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BNXJw-0004M6-00 for [e-mail]; Tue, 11 May 2004 09:29:21 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4BDSo915328 for <[e-mail]>; Tue, 11 May 2004 06:28:50 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4BDSjJ18192 for <[e-mail]>; Tue, 11 May 2004 06:28:45 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] comments on the Route Reflection implementation report
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 06:28:45 -0700

Folks,

If there are any comments on the implementation report (see below), please
send them to the list. The deadline for comments is May 18, 2004.

Yakov.
------- Forwarded Message

Date:    Mon, 10 May 2004 14:47:45 -0700
From:    Enke Chen <[e-mail]>
To:      [e-mail]
cc:      [e-mail]
Subject: [Idr] I-D ACTION:draft-chen-bgp-rfc2796bis-survey-00.txt

FYI.  -- Enke

- ------- Forwarded Message

To: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-chen-bgp-rfc2796bis-survey-00.txt
Date: Mon, 10 May 2004 16:20:46 -0400

- - --NextPart

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


	Title		: BGP Route Reflection - Implementation Report
	Author(s)	: E. Chen
	Filename	: draft-chen-bgp-rfc2796bis-survey-00.txt
	Pages		: 6
	Date		: 2004-5-10
	
This document provides an implementation report for the BGP Route
   Relection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-rfc2796bis-survey-00.txt

- ------- End of Forwarded Message


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

------- End of Forwarded Message


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA19180 for <[e-mail]>; Tue, 11 May 2004 09:38:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXOT-00054H-W2; Tue, 11 May 2004 09:34:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXKP-0004PO-OZ for [e-mail]; Tue, 11 May 2004 09:29:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25377 for <[e-mail]>; Tue, 11 May 2004 09:29:46 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNXKO-0004lE-1o for [e-mail]; Tue, 11 May 2004 09:29:48 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNXJR-0004Lr-00 for [e-mail]; Tue, 11 May 2004 09:28:49 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BNXIS-0003a1-00 for [e-mail]; Tue, 11 May 2004 09:27:49 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4BDQe914716; Tue, 11 May 2004 06:26:40 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4BDQYJ16888; Tue, 11 May 2004 06:26:35 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
cc: Sandy Murphy <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] change in  draft-ietf-idr-bgp-vuln-00.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 11 May 2004 06:26:34 -0700

Folks,

Sandy Murphy, the author of draft-ietf-idr-bgp-vuln-00.txt, proposed
the following change to her document, Replace 
  
  Spoofing a RST in this situation requires an attacker to guess a sequence 
  number that is in the proper half of the sending window,

with

  Spoofing a RST in this situation requires an attacker to guess a sequence 
  number that need only be within the receive window [9],

and add a [9] reference to the Paul Watson talk about the TCP RST
study he did.

The proposed change is intended to make the issue with TCP RST more
clear and accurate.

If there are any objections to the proposed change, please
send them to the list by May 18, 2004.

Yakov.

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA20172 for <[e-mail]>; Mon, 10 May 2004 18:52:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJQc-0006ok-Ll; Mon, 10 May 2004 18:39:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJHm-00046x-8x for [e-mail]; Mon, 10 May 2004 18:30:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12400 for <[e-mail]>; Mon, 10 May 2004 18:30:05 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNJHj-0004Og-3l for [e-mail]; Mon, 10 May 2004 18:30:07 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNJGn-00045K-00 for [e-mail]; Mon, 10 May 2004 18:29:09 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BNJGB-0003Y4-00 for [e-mail]; Mon, 10 May 2004 18:28:32 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 May 2004 14:33:45 +0000
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4AMRvW9009492; Mon, 10 May 2004 15:27:58 -0700 (PDT)
Received: from [192.168.42.3] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA07093; Mon, 10 May 2004 18:27:56 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p0602042cbcc5b07a96d7@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Mo Miri <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt
Cc: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 18:28:28 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id SAA20172

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16603 for <[e-mail]>; Mon, 10 May 2004 18:17:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIvN-0002lA-Bj; Mon, 10 May 2004 18:07:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIeE-0004ih-AI for [e-mail]; Mon, 10 May 2004 17:49:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08771 for <[e-mail]>; Mon, 10 May 2004 17:49:13 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNIeB-0005Wi-Ok for [e-mail]; Mon, 10 May 2004 17:49:15 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIdG-0005CF-00 for [e-mail]; Mon, 10 May 2004 17:48:19 -0400
Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BNIck-0004rM-00 for [e-mail]; Mon, 10 May 2004 17:47:46 -0400
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6A018A12084; Mon, 10 May 2004 14:47:46 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03232-02; Mon, 10 May 2004 14:47:46 -0700 (PDT)
Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 1CC07A12082; Mon, 10 May 2004 14:47:46 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id F1B3115D3C1; Mon, 10 May 2004 14:47:45 -0700 (PDT)
To: [e-mail]
Cc: [e-mail]
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] I-D ACTION:draft-chen-bgp-rfc2796bis-survey-00.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 14:47:45 -0700

FYI.  -- Enke

------- Forwarded Message

To: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-chen-bgp-rfc2796bis-survey-00.txt
Date: Mon, 10 May 2004 16:20:46 -0400

- --NextPart

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


	Title		: BGP Route Reflection - Implementation Report
	Author(s)	: E. Chen
	Filename	: draft-chen-bgp-rfc2796bis-survey-00.txt
	Pages		: 6
	Date		: 2004-5-10
	
This document provides an implementation report for the BGP Route
   Relection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-rfc2796bis-survey-00.txt

------- End of Forwarded Message


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16523 for <[e-mail]>; Mon, 10 May 2004 18:16:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNItT-00020O-PP; Mon, 10 May 2004 18:05:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEt0-00059x-A4 for [e-mail]; Mon, 10 May 2004 13:48:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19646 for <[e-mail]>; Mon, 10 May 2004 13:48:15 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNEsy-0005fG-2z for [e-mail]; Mon, 10 May 2004 13:48:16 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEsB-0005KR-00 for [e-mail]; Mon, 10 May 2004 13:47:28 -0400
Received: from im3.eng.bellsouth.net ([205.152.6.38] helo=mail.eng.bellsouth.net) by ietf-mx with esmtp (Exim 4.12) id 1BNErO-0004xi-00 for [e-mail]; Mon, 10 May 2004 13:46:38 -0400
Received: from [10.56.199.189] ([205.152.36.11]) by mail.eng.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040510174639.GBFX2065.mail.eng.bellsouth.net@[10.56.199.189]>; Mon, 10 May 2004 13:46:39 -0400
User-Agent: Microsoft-Entourage/10.1.4.030702.0
From: Mo Miri <[e-mail]>
To: <[e-mail]>
Message-ID: <[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3167041599_1111345"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no  version=2.60
Subject: [Idr] draft-chavali-bgp-prefixlimit-02.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 13:46:39 -0400

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3167041599_1111345
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

This document accurately outlines the capabilities of BGP and describers the
new additions (prefix limit).  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.

The Chavali draft seems easy to read and also provides adequate graphical
information for the interested fields and their placement in a BGP header.

Overall I believe this draft will be a valuable addition to BGP protocol
that will be used extensively by ISP networks.








--B_3167041599_1111345
Content-type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>draft-chavali-bgp-prefixlimit-02.txt</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:14.0px'>This document a=
ccurately outlines the capabilities of BGP and describers the new additions =
(prefix limit). &nbsp;One major difference in this document versus the other=
s recently submitted on the same topic, is the fact that BGP remains to be e=
stablished and only the prefixes outside the limit are dropped. &nbsp;Theref=
ore, the service remains to be reliable for the existing prefixes, which are=
 within the acceptable range.<BR>
<BR>
The Chavali draft seems easy to read and also provides adequate graphical i=
nformation for the interested fields and their placement in a BGP header.<BR=
>
<BR>
Overall I believe this draft will be a valuable addition to BGP protocol th=
at will be used extensively by ISP networks.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>


--B_3167041599_1111345--


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22039 for <[e-mail]>; Mon, 10 May 2004 14:17:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFE3-00027c-T9; Mon, 10 May 2004 14:10:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNF8I-0000VN-EN for [e-mail]; Mon, 10 May 2004 14:04:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20559 for <[e-mail]>; Mon, 10 May 2004 14:04:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNF8G-0003El-1v for [e-mail]; Mon, 10 May 2004 14:04:04 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNF7E-0002u0-00 for [e-mail]; Mon, 10 May 2004 14:03:01 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BNF6M-0002G1-00 for [e-mail]; Mon, 10 May 2004 14:02:06 -0400
Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4AI1YSu024051; Mon, 10 May 2004 11:01:34 -0700 (PDT)
Received: (from achandra@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA07327; Mon, 10 May 2004 11:01:33 -0700 (PDT)
From: Chandrashekhar Appanna <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 11:01:33 -0700

On Mon, May 10, 2004 at 10:55:50AM -0400, Jeffrey Haas wrote:
> 
> The primary difference with prefix-limits has been that simply
> discarding prefixes as a local matter is not as operationally
> serious as one of the other mechanisms of dealing with the problem:
> dropping the peering session.  Both mechanisms are operationally
> disruptive, but dropping the session is probably even more so.
>

  Each deployment/network has a different notion of how/which 
  prefixes to drop when the limit is exceeded. However, all of them
  do want to eventually penalize the sender by dropping the session
  because if the sender does not keep within SLA, it should not
  disrupt the network.  Keeping the session up and dropping 'some' 
  prefixes locally produces a forwarding state from the pov of the 
  sender that is not useful at all. In fact it is in general not 
  differentiable from a situation where a bug causes an announced 
  prefix to not get into the forwarding table, imho.

  Regards,
  Chandra Appanna.

> I think we should spend some of our time discussing the consequences
> of each of these actions regardless of the fact that each practice
> is currently well deployed.  Answering how we believe we should
> behave in these circumstances will probably help determine our behavior
> in any signalled prefix limit mechanism.
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA19768 for <[e-mail]>; Mon, 10 May 2004 13:49:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEnt-0004Nn-Ih; Mon, 10 May 2004 13:43:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEk4-0003gF-8B for [e-mail]; Mon, 10 May 2004 13:39:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19142 for <[e-mail]>; Mon, 10 May 2004 13:39:01 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNEk2-0002Va-26 for [e-mail]; Mon, 10 May 2004 13:39:02 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEjG-0002Ac-00 for [e-mail]; Mon, 10 May 2004 13:38:15 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BNEiX-0001nh-00 for [e-mail]; Mon, 10 May 2004 13:37:30 -0400
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 10 May 2004 10:37:12 -0700
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i4AHavjO012143; Mon, 10 May 2004 10:36:57 -0700 (PDT)
Received: from [192.168.42.3] (dhcp-64-101-214-222.cisco.com [64.101.214.222]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA21554; Mon, 10 May 2004 13:36:55 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p0602041ebcc56d7d3b03@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 13:37:27 -0400

At 6:47 AM -0700 5/10/04, Yakov Rekhter wrote:
>Those who were against accepting draft-chavali-bgp-prefixlimit-01.txt
>as an IDR WG document need to say whether they are still against
>accepting draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document,

Not sure if it even needs to be said, but I am still against it.  My 
reasons should be evident from on-list discussion of the last week or 
so -- in short, I'm OK with the idea of signalled prefix limits but 
not happy with the specific mechanisms chosen.

Regards,

--John

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA19336 for <[e-mail]>; Mon, 10 May 2004 13:43:57 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEk4-0003gw-Qh; Mon, 10 May 2004 13:39:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEhR-00032g-GN for [e-mail]; Mon, 10 May 2004 13:36:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19057 for <[e-mail]>; Mon, 10 May 2004 13:36:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNEhP-0001Uf-BW for [e-mail]; Mon, 10 May 2004 13:36:19 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEgg-00019A-00 for [e-mail]; Mon, 10 May 2004 13:35:35 -0400
Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BNEfY-0000iU-00 for [e-mail]; Mon, 10 May 2004 13:34:25 -0400
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i4AHXs5O057129; Mon, 10 May 2004 10:33:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i4AHXsZN057126; Mon, 10 May 2004 10:33:54 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: [Idr] signalled prefix limit as an IDR WG work item
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 10:33:54 -0700 (PDT)

Yakov Rekhter writes:

> Those who think that the IDR WG should not take signalled prefix
> limit as a work item, please speak up now.

It all depends on what is the expectation. I undertand the fact that
managing prefix-limits of costumer connections is a significant
operational problem.

What is not clear to me is what is the expected service model for this
after signalled prefix limits are agreed.

My understanding is that different people have different expectations
regarding what the mecanism is supposed to acomplish.

i.e. is the point simply to generate a warning limit in the customer
system ?

or is the fact that the limit is signaled something that just makes
life easier to the manager of the customer box ?

or is it a question of transfer of responsability for the session
reset ?

or is the expectation that the routers be inteligent enought to
understand which prefixes are "good" and should be mainatained and
which prefixes are "bad" and should be droped.

The latter is quite hard to define and not simple to implement in a
fail-proof way.

I would like to clearly define the problem and expectations before we
solve it... keep in mind that the more complex the problem definition
the higher the cost of a solution (and thus less likely to come
about).

  Pedro.  

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA19114 for <[e-mail]>; Mon, 10 May 2004 13:41:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEk1-0003fg-PT; Mon, 10 May 2004 13:39:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEeH-0002Xw-Rq for [e-mail]; Mon, 10 May 2004 13:33:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18830 for <[e-mail]>; Mon, 10 May 2004 13:33:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNEeF-0000Ng-NA for [e-mail]; Mon, 10 May 2004 13:33:03 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEdQ-00001X-00 for [e-mail]; Mon, 10 May 2004 13:32:13 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BNEci-0007RB-00 for [e-mail]; Mon, 10 May 2004 13:31:28 -0400
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i4AHUkjO005443; Mon, 10 May 2004 10:30:47 -0700 (PDT)
Received: from [192.168.42.3] (dhcp-64-101-214-222.cisco.com [64.101.214.222]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA21219; Mon, 10 May 2004 13:30:46 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p0602041bbcc557c423c0@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
To: Jeffrey Haas <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 13:31:18 -0400

At 10:55 AM -0400 5/10/04, Jeffrey Haas wrote:
...
>The primary difference with prefix-limits has been that simply
>discarding prefixes as a local matter is not as operationally
>serious as one of the other mechanisms of dealing with the problem:
>dropping the peering session.  Both mechanisms are operationally
>disruptive, but dropping the session is probably even more so.

You think so?  I'm not so sure.  Dropping routes on the floor can be 
substantially harder to debug.  Consider the differences in the 
failure modes --

If you drop the session, both parties know right away that something 
is broken.  There will be immediate attention to the problem while 
the cause is still evident.

If you drop prefixes, there's a real risk that the party whose 
prefixes are dropped won't notice until later, potentially quite a 
bit later.  By that time the session may even have fallen below the 
maximum again, while remaining unsynchronized due to the prior route 
droppage.  In any event, it's almost inevitable that diagnosing the 
problem will be more challenging.  Fundamentally, problems where 
connectivity is semi-broken are harder to debug than those where it's 
all broken.

>I think we should spend some of our time discussing the consequences
>of each of these actions regardless of the fact that each practice
>is currently well deployed.

I believe that the "drop the session" behavior is well deployed.  I 
have my doubts about the "drop the prefix" behavior.  This in itself 
is instructive.

>Answering how we believe we should
>behave in these circumstances will probably help determine our behavior
>in any signalled prefix limit mechanism.

I think that if we were so foolish as to adopt a spec that tried to 
exclude one approach or the other, we'd just end up with nonstandard 
vendor-specific knobs anyway, since some folks will prefer one 
approach, some the other.

Regards,

--John

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA07302 for <[e-mail]>; Mon, 10 May 2004 11:16:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCLy-0007oE-Bf; Mon, 10 May 2004 11:06:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCFA-0006cM-RV for [e-mail]; Mon, 10 May 2004 10:59:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09466 for <[e-mail]>; Mon, 10 May 2004 10:58:56 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNCF8-0001e0-7z for [e-mail]; Mon, 10 May 2004 10:58:58 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNCE0-0001Ed-00 for [e-mail]; Mon, 10 May 2004 10:57:48 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BNCCr-0000VU-00 for [e-mail]; Mon, 10 May 2004 10:56:37 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3FB732D4866; Mon, 10 May 2004 10:56:02 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 37681-04-16; Mon, 10 May 2004 10:55:50 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D131A2D4880; Mon, 10 May 2004 10:55:50 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i4AEtoG23736; Mon, 10 May 2004 10:55:50 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, May 10, 2004 at 07:17:53AM -0700
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 10:55:50 -0400

Yakov,

On Mon, May 10, 2004 at 07:17:53AM -0700, Yakov Rekhter wrote:
> As we discuss relative merits of two approaches to signal prefix
> limit, draft-chavali-bgp-prefixlimit-02.txt and
> draft-keyur-prefixlimit-orf-00.txt, we also need to step back and
> ask whether there is a WG consensus to take signalled prefix limit
> as a work item.

I haven't had the opportunity to review the merits of either of
these documents, but speaking with my hat as BGP MIB editor, one
of the most requested features out of the V2 MIB has been better
counters for prefixes on a per-AFI/SAFI basis.

A signaled prefix limit mechanism of some sort seems like it would
also help fill this need.  The MIB allows localized management
of the limits, a singalling mechanism allows one to communicate
localized policy.

Regardless of the approach, the thing that has been mentioned during
discussion of this issue has been, "Why do we care?"  Prefix limits
are similar to other elements of BGP policy almost all of which have
previously been local matters.  

The primary difference with prefix-limits has been that simply
discarding prefixes as a local matter is not as operationally
serious as one of the other mechanisms of dealing with the problem:
dropping the peering session.  Both mechanisms are operationally
disruptive, but dropping the session is probably even more so.

I think we should spend some of our time discussing the consequences
of each of these actions regardless of the fact that each practice
is currently well deployed.  Answering how we believe we should
behave in these circumstances will probably help determine our behavior
in any signalled prefix limit mechanism.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA03786 for <[e-mail]>; Mon, 10 May 2004 10:34:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBkJ-0001mD-T9; Mon, 10 May 2004 10:27:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBep-0000ag-1U for [e-mail]; Mon, 10 May 2004 10:21:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07384 for <[e-mail]>; Mon, 10 May 2004 10:21:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNBem-0004ER-RF for [e-mail]; Mon, 10 May 2004 10:21:24 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNBde-0003nf-00 for [e-mail]; Mon, 10 May 2004 10:20:17 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BNBbx-0002uM-00 for [e-mail]; Mon, 10 May 2004 10:18:29 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4AEHw907024 for <[e-mail]>; Mon, 10 May 2004 07:17:58 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4AEHrJ64783 for <[e-mail]>; Mon, 10 May 2004 07:17:53 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] signalled prefix limit as an IDR WG work item
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 07:17:53 -0700

Folks,

To answer the first question raised by John Scudder in the attached...

As we discuss relative merits of two approaches to signal prefix
limit, draft-chavali-bgp-prefixlimit-02.txt and
draft-keyur-prefixlimit-orf-00.txt, we also need to step back and
ask whether there is a WG consensus to take signalled prefix limit
as a work item.

For the purpose of measuring consensus on whether the WG should
take signalled prefix limit as a work item, it will be assumed that
those who are in favor of either of the two approaches mentioned
above as being also in favor of taking signalled prefix limit as
a work item (if this assumption is incorrect, please speak up now).

Those who think that the IDR WG should not take signalled prefix
limit as a work item, please speak up now.

The deadline for comments is May 24, 2004.

Yakov.
------- Forwarded Message
To: [e-mail]
From: "John G. Scudder" <[e-mail]>
Subject: [Idr] signalled prefix limits -- contrasting approaches
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr
------- End of Forwarded Message


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01489 for <[e-mail]>; Mon, 10 May 2004 10:06:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBI9-0007ZQ-5y; Mon, 10 May 2004 09:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBBX-0006WV-E1 for [e-mail]; Mon, 10 May 2004 09:51:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03942 for <[e-mail]>; Mon, 10 May 2004 09:51:07 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNBBV-0001Q5-Ei for [e-mail]; Mon, 10 May 2004 09:51:09 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNBA3-0000kX-00 for [e-mail]; Mon, 10 May 2004 09:49:39 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BNB8h-00006x-00 for [e-mail]; Mon, 10 May 2004 09:48:15 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4ADlhBm081970 for <[e-mail]>; Mon, 10 May 2004 06:47:43 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4ADlhJ62075 for <[e-mail]>; Mon, 10 May 2004 06:47:43 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 06:47:43 -0700

Folks,

Those who were in favor of accepting draft-chavali-bgp-prefixlimit-01.txt
as an IDR WG document need to say whether they are in favor of
accepting draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document.

Those who were against accepting draft-chavali-bgp-prefixlimit-01.txt
as an IDR WG document need to say whether they are still against
accepting draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document,
or whether draft-chavali-bgp-prefixlimit-02.txt addressed their
objections, and they are now in favor of accepting 
draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document.

And finally, comments from the folks who did not express their
opinion on draft-chavali-bgp-prefixlimit-01.txt would be
greatly appreciated.

Yakov.
------- Forwarded Message

Date:    Sun, 02 May 2004 08:50:26 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
Subject: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document

Folks,

We didn't get sufficient consensus to accept 
draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document. 

The authors of draft-chavali-bgp-prefixlimit-01.txt produced
a new version, draft-chavali-bgp-prefixlimit-02.txt, and would
like the IDR WG to accept this *new* version as an IDR WG document.

Please send comments to the list. The deadline for comments is 
May 17, 2004.

Yakov. 

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

------- End of Forwarded Message


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA00715 for <[e-mail]>; Mon, 10 May 2004 09:57:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBBN-0006RG-LY; Mon, 10 May 2004 09:51:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNB5q-0005Me-UX for [e-mail]; Mon, 10 May 2004 09:45:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03534 for <[e-mail]>; Mon, 10 May 2004 09:45:15 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNB5p-0006xW-3k for [e-mail]; Mon, 10 May 2004 09:45:17 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNB4O-0006a4-00 for [e-mail]; Mon, 10 May 2004 09:43:48 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BNB3D-0005sV-00 for [e-mail]; Mon, 10 May 2004 09:42:36 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4ADg5906882 for <[e-mail]>; Mon, 10 May 2004 06:42:05 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4ADg0J61448 for <[e-mail]>; Mon, 10 May 2004 06:42:00 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] draft-keyur-prefixlimit-orf-00.txt as an IDR WG document
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 May 2004 06:42:00 -0700

Folks,

We received a request to accept draft-keyur-prefixlimit-orf-00.txt
as an IDR WG document. Please send comments to the list. The deadline
for comments is May 24, 2004. 

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA21998 for <[e-mail]>; Fri, 7 May 2004 19:18:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMEWb-0001em-OV; Fri, 07 May 2004 19:13:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMESD-0000Mk-4L for [e-mail]; Fri, 07 May 2004 19:08:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27475 for <[e-mail]>; Fri, 7 May 2004 19:08:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMES9-0000vi-H5 for [e-mail]; Fri, 07 May 2004 19:08:25 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMERB-0000Sg-00 for [e-mail]; Fri, 07 May 2004 19:07:26 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BMEQ2-0007N4-00 for [e-mail]; Fri, 07 May 2004 19:06:14 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 07 May 2004 15:09:15 +0000
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i47N5fW9012467; Fri, 7 May 2004 16:05:41 -0700 (PDT)
Received: from [192.168.42.3] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA27991; Fri, 7 May 2004 19:05:39 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p06020401bcc1c4844a26@[192.168.42.3]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
To: "Fang, Luyuan, ALABS" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
Cc: "Srikanth Chavali" <[e-mail]>, "Keyur Patel" <[e-mail]>, "idr" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 7 May 2004 19:05:44 -0400

Luyuan,

I certainly don't mean to question that there is operational goodness 
from having warnings emitted by customer boxes.  In fact, I agree.

Rather, my point is that the warning doesn't need to be sent by the 
provider side box to the customer side box.  Since the provider box 
would tell the customer box the prefix limit ahead of time, and since 
the customer box knows the size of its own Adj-RIB-Out towards the 
provider box, the customer box can and should generate the warning 
locally.

The effect would be the same, the difference being that one approach 
requires extra messaging and one doesn't.  In either case, the 
customer receives a warning when the limit is reached.

Note that no matter what, some aspect of the warning is beyond the 
provider box's control -- even if we went with a solution where the 
provider box transmits a warning to the customer box, the customer 
box still has to properly present that warning to the customer as a 
log message, SNMP trap, or whatnot.  So, regardless of whether 
warnings are generated locally or remotely, it's inescapable that the 
customer box controls whether and how the warning is delivered. 
Given that, why would we want to go to the effort of generating them 
remotely instead of getting the same benefit for lower cost by doing 
it locally?

Thanks,

--John

At 5:44 PM -0500 5/7/04, Fang, Luyuan, ALABS wrote:
>This warning mechanism is useful from the perspective of operations. 
>With the external messages it ensures that the customers receive the 
>warning on the limit reached condition and take immediate actions, 
>rather than for the service providers  manually calling up the 
>customers.
>
>This might not be applied to all the BGP peers but to some of the 
>peers that we deem fit for it.
>
>Since it can be turned off, it should limit the impact from the 
>processing standpoint. Of course, if this consumes fair amount of 
>resources of the boxes, we need to take that into consideration.
>
>Luyuan Fang
>[e-mail]
>
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On Behalf Of John G.
>Scudder
>Sent: Thursday, May 06, 2004 10:55 PM
>To: Srikanth Chavali
>Cc: Keyur Patel; idr
>Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
>IDR WG document]
>
>
>Srikanth,
>
>Yes, I read -00 back around the Minneapolis meeting.  Is there a
>specific section of the document you believe addresses the questions?
>Since you refer to "service providers perspective" I went and reread
>section 2.2 of -00 ("Current Service Provider Perspective") and it
>doesn't appear to answer either question.
>
>Note that I don't need to be convinced of the value of issuing
>warnings.  Rather, I'm questioning if they need to be remotely
>signalled.
>
>Regards,
>
>--John
>
>At 9:59 PM -0400 5/6/04, Srikanth Chavali wrote:
>>Keyur/John,
>>                   Did you guys had a chance to read 00.txt vesion of
>>this draft? We had incorporated the views of the Service Providers
>>and the discussions we had with them there. If you did'nt let me
>>know i will either point you to that or send you a copy of it.  That
>>should answer your questions as well as the service providers
>>perspective on that.  In the latest versions we had trimmed that
>>text for simplicity sake.
>>
>>srikanth chavali
>>
>>Keyur Patel wrote:
>>
>>>Also, can you comment on as to why the "reset prefix limit" as a
>>>part of local policy is not sufficient (considering this *may* be
>>>taken into consideration when prefix limits have already been
>>>reached)? Resetting the session is just one of the possible local
>>>actions that can be taken (when the prefix limit is reached). Why
>>>just enumerate one of them in the draft?
>>>
>>>-Keyur
>>>
>>>John G. Scudder wrote:
>>>
>>>>Srikanth,
>>>>
>>>>At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>>>>
>>>>>2. If warning limit hit send the Dynamic capability (if indicator set).
>  >>>>It serves dual purpose as warning and/or renegotiate the capabilites.
>>>>>It gives operators enough time to (debug errors)/(change limits).
>>>>
>>>>
>>>>
>>>>Can you comment as to why warning as a local policy is not
>>>>sufficient to achieve this end?
>>>>
>>>>In particular it would be great if you could address the
>>>>observation that whether generated locally or remotely, the
>>>>warning is liable to be a function of the Adj-RIB size (which is
>>>>known by both peers) and the prefix-limit value (which is likewise
>>>>known to both peers). Furthermore the action of the router to
>>>>bring the warning to the attention of the operator is inherently
>>>>going to be a local matter.
>>>>
>>>>Thanks,
>>>>
>>>>--John
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA20142 for <[e-mail]>; Fri, 7 May 2004 18:56:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMEDF-00048P-Nf; Fri, 07 May 2004 18:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BME7Y-0002VH-TC for [e-mail]; Fri, 07 May 2004 18:47:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26171 for <[e-mail]>; Fri, 7 May 2004 18:47:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BME7V-0007K2-O6 for [e-mail]; Fri, 07 May 2004 18:47:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BME6W-0006uh-00 for [e-mail]; Fri, 07 May 2004 18:46:05 -0400
Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BME5N-00067O-00 for [e-mail]; Fri, 07 May 2004 18:44:53 -0400
Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i47MhaCG011459 for <[e-mail]>; Fri, 7 May 2004 17:44:19 -0500
Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 408F16A60026BB66; Fri, 7 May 2004 18:44:17 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
Message-ID: <[e-mail]>
Thread-Topic: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
Thread-Index: AcQz4P3gTkb67iIeQeSxa5fIU0ejIAAohDTQ
From: "Fang, Luyuan, ALABS" <[e-mail]>
To: "John G. Scudder" <[e-mail]>, "Srikanth Chavali" <[e-mail]>
Cc: "Keyur Patel" <[e-mail]>, "idr" <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 7 May 2004 17:44:18 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id SAA20142

This warning mechanism is useful from the perspective of operations. With the external messages it ensures that the customers receive the warning on the limit reached condition and take immediate actions, rather than for the service providers  manually calling up the customers.

This might not be applied to all the BGP peers but to some of the peers that we deem fit for it. 

Since it can be turned off, it should limit the impact from the processing standpoint. Of course, if this consumes fair amount of resources of the boxes, we need to take that into consideration.

Luyuan Fang
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of John G.
Scudder
Sent: Thursday, May 06, 2004 10:55 PM
To: Srikanth Chavali
Cc: Keyur Patel; idr
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an
IDR WG document]


Srikanth,

Yes, I read -00 back around the Minneapolis meeting.  Is there a 
specific section of the document you believe addresses the questions? 
Since you refer to "service providers perspective" I went and reread 
section 2.2 of -00 ("Current Service Provider Perspective") and it 
doesn't appear to answer either question.

Note that I don't need to be convinced of the value of issuing 
warnings.  Rather, I'm questioning if they need to be remotely 
signalled.

Regards,

--John

At 9:59 PM -0400 5/6/04, Srikanth Chavali wrote:
>Keyur/John,
>                  Did you guys had a chance to read 00.txt vesion of 
>this draft? We had incorporated the views of the Service Providers 
>and the discussions we had with them there. If you did'nt let me 
>know i will either point you to that or send you a copy of it.  That 
>should answer your questions as well as the service providers 
>perspective on that.  In the latest versions we had trimmed that 
>text for simplicity sake.
>
>srikanth chavali
>
>Keyur Patel wrote:
>
>>Also, can you comment on as to why the "reset prefix limit" as a 
>>part of local policy is not sufficient (considering this *may* be 
>>taken into consideration when prefix limits have already been 
>>reached)? Resetting the session is just one of the possible local 
>>actions that can be taken (when the prefix limit is reached). Why 
>>just enumerate one of them in the draft?
>>
>>-Keyur
>>
>>John G. Scudder wrote:
>>
>>>Srikanth,
>>>
>>>At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>>>
>>>>2. If warning limit hit send the Dynamic capability (if indicator set).
>>>>It serves dual purpose as warning and/or renegotiate the capabilites.
>>>>It gives operators enough time to (debug errors)/(change limits).
>>>
>>>
>>>
>>>Can you comment as to why warning as a local policy is not 
>>>sufficient to achieve this end?
>>>
>>>In particular it would be great if you could address the 
>>>observation that whether generated locally or remotely, the 
>>>warning is liable to be a function of the Adj-RIB size (which is 
>>>known by both peers) and the prefix-limit value (which is likewise 
>>>known to both peers). Furthermore the action of the router to 
>>>bring the warning to the attention of the operator is inherently 
>>>going to be a local matter.
>>>
>>>Thanks,
>>>
>>>--John

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

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16383 for <[e-mail]>; Fri, 7 May 2004 18:08:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDRp-0003RZ-9d; Fri, 07 May 2004 18:04:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDKF-0007Ud-Ea for [e-mail]; Fri, 07 May 2004 17:56:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23123 for <[e-mail]>; Fri, 7 May 2004 17:56:07 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMDKC-00017T-SM for [e-mail]; Fri, 07 May 2004 17:56:08 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMDJI-0000hb-00 for [e-mail]; Fri, 07 May 2004 17:55:13 -0400
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BMDIT-0007dn-00 for [e-mail]; Fri, 07 May 2004 17:54:21 -0400
Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i47LrZB08192; Fri, 7 May 2004 17:53:35 -0400 (EDT)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KJ4L8Z28; Fri, 7 May 2004 17:53:34 -0400
Received: from nortelnetworks.com (schavali-3.engeast.baynetworks.com [192.32.145.188]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCN024DA; Fri, 7 May 2004 17:53:34 -0400
Message-ID: <[e-mail]>
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Srikanth Chavali <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Chandrashekhar Appanna <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------050809020707050705030004"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 07 May 2004 17:53:32 -0400

This is a multi-part message in MIME format.
--------------050809020707050705030004
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Chandra ,
              At the point this was written there was no other way of 
information messaging. We did have
Notification in mind per AFI/SAFI with non-fatal codes/subcodes i.e non 
peer session tearing in nature and
which would not impact the FSM. However since Dynamic capability was 
readily available we chose that.
If you see any specific issues with this we can discuss on ways to 
achieve the Notification way i described above.
We're open for discussions on that.

Thanks

srikanth chavali

Chandrashekhar Appanna wrote:

>  Dynamic capability is not intended as a signalling mechanism of
>  state - that is how I see it. It is mainly to exchange high level
>  session capabilities.  I would rather use a different mechanism that 
>  is for the purpose of such exchanging dynamic state changes.
>
>  To quote from the DYN-CAP draft :
>
>   -------------
>   Currently BGP capabilities [BGP-CAP] are only advertised in the OPEN
>   message during the session initialization. In order to enable a new
>   capability or remove an existing capability (such as an Address
>   Family support [BGP-MP]), an established session may need to be
>   reset, which would disrupt other services running over the session.
>   -------------
>
>  I would like to understand why the authors think that dynamic
>  capabilites is an appropriate medium for this purpose.
>
>  thanks,
>  Chandra Appanna.
>
>
>
>On Thu, May 06, 2004 at 08:23:16PM -0400, Srikanth Chavali wrote:
>  
>
>>I am forwarding my response to Pekka's email to clarify things..
>>
>>srikanth chavali
>>
>>-------- Original Message --------
>>Subject: 	Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG 
>>document
>>Date: 	Wed, 05 May 2004 10:37:02 -0400
>>From: 	Srikanth Chavali <[e-mail]>
>>To: 	Pekka Savola <[e-mail]>, [e-mail]
>>References: 	<[e-mail]>
>>
>>
>>
>>Hi Pekka,
>>             Thanks for your comments. I have replied to your model 
>>related comments:
>>
>>Pekka Savola wrote:
>>
>>    
>>
>>>A high-level comment:
>>>---------------------
>>>
>>>The model seems to be so that when the receiving BGP speaker receives the
>>>number of routes which exceed a warning, stop or reset limit, it sends a
>>>message to inform the other router about exceeding this limit, raising a
>>>warning, askit it to stop, or reset the session.
>>>
>>>      
>>>
>>The draft does'nt say/mean/intend this.
>>
>>    
>>
>>>There is another way to specify this as well.  Each router sends the 
>>>other,
>>>_in advance_, when opening the BGP session, their prefix limits; these
>>>values are stored per peer.  The sending router checks the length of its
>>>adj-ribs-out for the peer whether it exceeds any of these limits, and 
>>>raises
>>>warnings, stops advertising, etc. as appropriate.  (In that model, no 
>>>compliant router ever exceeds these limits, even temporarily.)
>>>
>>>      
>>>
>>The above is what the draft specifies. Please note that the exchange of 
>>the prefix limit capability in the OPEN
>>message (Not the Dynamic capability) achieves what you're saying above. 
>>This is already specified in the draft.
>>
>>So here's the mechanism in short:
>>
>>1. Exchange the capability in OPEN message. The BGP speakers note them 
>>and are expected to honor them.
>>2. If warning limit hit send the Dynamic capability (if indicator set). 
>>It serves dual purpose as warning and/or renegotiate the capabilites.
>>It gives operators enough time to (debug errors)/(change limits).
>>3. If stop limit hit stop route advertisements. Again send Dynamic 
>>capability whose purpose is as mentioned in 2.
>>
>>We're working on revising the text for clarity, but if there's anything 
>>specific in the text which caused mis-interpretation please
>>let us know and we will address it.
>>
>>Thanks
>>
>>srikanth chavali
>>
>>
>>
>>    
>>
>
>  
>

--------------050809020707050705030004
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Chandra ,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; At the point this was written there was no other way of
information messaging. We did have <br>
Notification in mind per AFI/SAFI with non-fatal codes/subcodes i.e non
peer session tearing in nature and<br>
which would not impact the FSM. However since Dynamic capability was
readily available we chose that.<br>
If you see any specific issues with this we can discuss on ways to
achieve the Notification way i described above.<br>
We're open for discussions on that.<br>
<br>
Thanks<br>
<br>
srikanth chavali<br>
<br>
Chandrashekhar Appanna wrote:<br>
<blockquote type="cite" cite="[e-mail]">
  <pre wrap="">  Dynamic capability is not intended as a signalling mechanism of
  state - that is how I see it. It is mainly to exchange high level
  session capabilities.  I would rather use a different mechanism that 
  is for the purpose of such exchanging dynamic state changes.

  To quote from the DYN-CAP draft :

   -------------
   Currently BGP capabilities [BGP-CAP] are only advertised in the OPEN
   message during the session initialization. In order to enable a new
   capability or remove an existing capability (such as an Address
   Family support [BGP-MP]), an established session may need to be
   reset, which would disrupt other services running over the session.
   -------------

  I would like to understand why the authors think that dynamic
  capabilites is an appropriate medium for this purpose.

  thanks,
  Chandra Appanna.



On Thu, May 06, 2004 at 08:23:16PM -0400, Srikanth Chavali wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I am forwarding my response to Pekka's email to clarify things..

srikanth chavali

-------- Original Message --------
Subject: 	Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG 
document
Date: 	Wed, 05 May 2004 10:37:02 -0400
From: 	Srikanth Chavali <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
To: 	Pekka Savola <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>, <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
References: 	<a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>



Hi Pekka,
             Thanks for your comments. I have replied to your model 
related comments:

Pekka Savola wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">A high-level comment:
---------------------

The model seems to be so that when the receiving BGP speaker receives the
number of routes which exceed a warning, stop or reset limit, it sends a
message to inform the other router about exceeding this limit, raising a
warning, askit it to stop, or reset the session.

      </pre>
    </blockquote>
    <pre wrap="">The draft does'nt say/mean/intend this.

    </pre>
    <blockquote type="cite">
      <pre wrap="">There is another way to specify this as well.  Each router sends the 
other,
_in advance_, when opening the BGP session, their prefix limits; these
values are stored per peer.  The sending router checks the length of its
adj-ribs-out for the peer whether it exceeds any of these limits, and 
raises
warnings, stops advertising, etc. as appropriate.  (In that model, no 
compliant router ever exceeds these limits, even temporarily.)

      </pre>
    </blockquote>
    <pre wrap="">The above is what the draft specifies. Please note that the exchange of 
the prefix limit capability in the OPEN
message (Not the Dynamic capability) achieves what you're saying above. 
This is already specified in the draft.

So here's the mechanism in short:

1. Exchange the capability in OPEN message. The BGP speakers note them 
and are expected to honor them.
2. If warning limit hit send the Dynamic capability (if indicator set). 
It serves dual purpose as warning and/or renegotiate the capabilites.
It gives operators enough time to (debug errors)/(change limits).
3. If stop limit hit stop route advertisements. Again send Dynamic 
capability whose purpose is as mentioned in 2.

We're working on revising the text for clarity, but if there's anything 
specific in the text which caused mis-interpretation please
let us know and we will address it.

Thanks

srikanth chavali



    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>

--------------050809020707050705030004--


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA10007 for <[e-mail]>; Fri, 7 May 2004 10:42:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5xZ-0002qk-Ge; Fri, 07 May 2004 10:04:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5ei-0003Hc-Gw for [e-mail]; Fri, 07 May 2004 09:44:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21745 for <[e-mail]>; Fri, 7 May 2004 09:44:45 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM5eg-0000wK-Fg for [e-mail]; Fri, 07 May 2004 09:44:46 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM5dp-0000Vu-00 for [e-mail]; Fri, 07 May 2004 09:43:53 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BM5cz-0007Pg-00 for [e-mail]; Fri, 07 May 2004 09:43:01 -0400
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i47DgSC1025849; Fri, 7 May 2004 06:42:28 -0700 (PDT)
Received: from [192.168.42.3] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA01850; Fri, 7 May 2004 09:42:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p060204cfbcc127f29255@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Pekka Savola <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
Cc: Srikanth Chavali <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 7 May 2004 09:42:54 -0400

At 8:12 AM +0300 5/7/04, Pekka Savola wrote:
>On Thu, 6 May 2004, John G. Scudder wrote:
>>  At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>>  >2. If warning limit hit send the Dynamic capability (if indicator set).
>>  >It serves dual purpose as warning and/or renegotiate the capabilites.
>>  >It gives operators enough time to (debug errors)/(change limits).
>>
>>  Can you comment as to why warning as a local policy is not sufficient
>>  to achieve this end?
>
>I'm not sure if I understand the point 2, above.

Just to be sure we all understand each other, point 2 above is 
Srikanth, the question below it which refers to local policy it is 
me.  Multiple quote levels can get confusing.

>(I'm not sure which router's "local policy" are you talking about.)

I was referring to the (warning generation) policy on Speaker A in 
your example quoted below.  The text that you omitted from your quote 
elaborates on the question, but my point is that A can and should 
generate the warning on its own, B doesn't need to signal A telling 
it when to generate a warning.  It's sufficient for B to tell A ahead 
of time what the maximum limit is, and rely on A to notice when it's 
approaching it.

In other words, I think we're agreeing on this point -- at any rate I 
agree with the way you've written out the scenario in your example. 
What I do NOT think is needed is if the example were instead to say:

"When the Adj-RIB-In on B (from A) reaches the warning level, B sends 
A a message requesting that A log a warning message to its 
administration."

which is what I understand draft-chavali to propose.  I don't think B 
needs to nag A -- A already knows how many routes it has sent as 
you've shown in your example.

>Yes, prefix-limits should not be re-negotiated when a limit has been
>hit.  That's part of the administrative procedures.
>
>Yes, it would also seem ill-advised to send the "you have exceeded
>your prefix limits" -message after the exceeding, as the damage has
>already been done.
>
>Let's assume BGP speaker A advertises prefixes to speaker B, and B has
>set up prefix limits and wishes to inform A about them.
>
>The BGP speaker A must support at least a warning level, and may
>support also "code red" level.  That is, when Adj-Ribs-out (for B) on
>speaker A reaches the warning level, log a warning message to the
>administration of speaker A.  When the advertised prefix count on A
>reaches the "code red" level, it needs to log a "code red" message,
>and may stop advertising new prefixes.  The stopping part is IMHO not
>that important.
[snip]

Regards,

--John

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA26201 for <[e-mail]>; Fri, 7 May 2004 01:24:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxo9-0007Iz-Rl; Fri, 07 May 2004 01:22:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxhn-0005X4-NY for [e-mail]; Fri, 07 May 2004 01:15:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11844 for <[e-mail]>; Fri, 7 May 2004 01:15:25 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLxhk-0005qt-Q7 for [e-mail]; Fri, 07 May 2004 01:15:24 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLxgp-0005Si-00 for [e-mail]; Fri, 07 May 2004 01:14:27 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BLxgU-000548-00 for [e-mail]; Fri, 07 May 2004 01:14:06 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i475CTs26552; Fri, 7 May 2004 08:12:29 +0300
From: Pekka Savola <[e-mail]>
To: "John G. Scudder" <[e-mail]>
cc: Srikanth Chavali <[e-mail]>, <[e-mail]>
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
In-Reply-To: <p060204cabcc08daf6a96@[192.168.42.3]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 7 May 2004 08:12:29 +0300 (EEST)

On Thu, 6 May 2004, John G. Scudder wrote:
> At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
> >2. If warning limit hit send the Dynamic capability (if indicator set).
> >It serves dual purpose as warning and/or renegotiate the capabilites.
> >It gives operators enough time to (debug errors)/(change limits).
> 
> Can you comment as to why warning as a local policy is not sufficient 
> to achieve this end?

I'm not sure if I understand the point 2, above.  (I'm not sure which 
router's "local policy" are you talking about.)

Yes, prefix-limits should not be re-negotiated when a limit has been 
hit.  That's part of the administrative procedures.

Yes, it would also seem ill-advised to send the "you have exceeded 
your prefix limits" -message after the exceeding, as the damage has 
already been done.

Let's assume BGP speaker A advertises prefixes to speaker B, and B has 
set up prefix limits and wishes to inform A about them.

The BGP speaker A must support at least a warning level, and may
support also "code red" level.  That is, when Adj-Ribs-out (for B) on
speaker A reaches the warning level, log a warning message to the
administration of speaker A.  When the advertised prefix count on A
reaches the "code red" level, it needs to log a "code red" message,
and may stop advertising new prefixes.  The stopping part is IMHO not
that important.

On the other hand, Speaker B has set prefix limits to the direction of 
A.  If the advertised prefix count exceed the warning level, a warning 
is logged to the local administration.  If the prefix count exceeds 
the "code red" level, stop accepting new prefixes or reset the 
session and log a "code red" alert.  Note that these have to be done 
always and in any way, because speaker B cannot be sure that speaker A 
is honoring the limits it has sent.  If A honors them, most of these 
errors never get activated.

And just to clarify -- the part about speaker B is already out there 
and requires no notifications at all.  The part people are interested 
of is notifying another BGP speakers of the configured and enforced 
limits, so that the other speakers can log local warning messages or 
prevent the bgp sessions from being reset.

(I don't have have strong opinions on whether it's needed to be able 
to send other limits rather than just the warning.  The warning is 
most important, but the stop might be useful as well.  Reset doesn't 
appear to be necessary at all.)

Hope this clarifies the "scenarios" or "operator requirements" I had 
in mind.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA17845 for <[e-mail]>; Thu, 6 May 2004 23:04:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvcf-0003WQ-Pd; Thu, 06 May 2004 23:02:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvZL-0001tc-3f for [e-mail]; Thu, 06 May 2004 22:58:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06413 for <[e-mail]>; Thu, 6 May 2004 22:58:30 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLvZH-0005Pv-JN for [e-mail]; Thu, 06 May 2004 22:58:31 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLvY1-0004wW-00 for [e-mail]; Thu, 06 May 2004 22:57:14 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BLvX0-000499-00 for [e-mail]; Thu, 06 May 2004 22:56:11 -0400
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i472tcC1023543; Thu, 6 May 2004 19:55:39 -0700 (PDT)
Received: from [192.168.42.3] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA09009; Thu, 6 May 2004 22:55:37 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p060204ccbcc0aaa333c1@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p060204cabcc08daf6a96@[192.168.42.3]> <[e-mail]> <[e-mail]>
To: Srikanth Chavali <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR  WG document]
Cc: Keyur Patel <[e-mail]>, idr <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 6 May 2004 22:55:25 -0400

Srikanth,

Yes, I read -00 back around the Minneapolis meeting.  Is there a 
specific section of the document you believe addresses the questions? 
Since you refer to "service providers perspective" I went and reread 
section 2.2 of -00 ("Current Service Provider Perspective") and it 
doesn't appear to answer either question.

Note that I don't need to be convinced of the value of issuing 
warnings.  Rather, I'm questioning if they need to be remotely 
signalled.

Regards,

--John

At 9:59 PM -0400 5/6/04, Srikanth Chavali wrote:
>Keyur/John,
>                  Did you guys had a chance to read 00.txt vesion of 
>this draft? We had incorporated the views of the Service Providers 
>and the discussions we had with them there. If you did'nt let me 
>know i will either point you to that or send you a copy of it.  That 
>should answer your questions as well as the service providers 
>perspective on that.  In the latest versions we had trimmed that 
>text for simplicity sake.
>
>srikanth chavali
>
>Keyur Patel wrote:
>
>>Also, can you comment on as to why the "reset prefix limit" as a 
>>part of local policy is not sufficient (considering this *may* be 
>>taken into consideration when prefix limits have already been 
>>reached)? Resetting the session is just one of the possible local 
>>actions that can be taken (when the prefix limit is reached). Why 
>>just enumerate one of them in the draft?
>>
>>-Keyur
>>
>>John G. Scudder wrote:
>>
>>>Srikanth,
>>>
>>>At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>>>
>>>>2. If warning limit hit send the Dynamic capability (if indicator set).
>>>>It serves dual purpose as warning and/or renegotiate the capabilites.
>>>>It gives operators enough time to (debug errors)/(change limits).
>>>
>>>
>>>
>>>Can you comment as to why warning as a local policy is not 
>>>sufficient to achieve this end?
>>>
>>>In particular it would be great if you could address the 
>>>observation that whether generated locally or remotely, the 
>>>warning is liable to be a function of the Adj-RIB size (which is 
>>>known by both peers) and the prefix-limit value (which is likewise 
>>>known to both peers). Furthermore the action of the router to 
>>>bring the warning to the attention of the operator is inherently 
>>>going to be a local matter.
>>>
>>>Thanks,
>>>
>>>--John

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA14866 for <[e-mail]>; Thu, 6 May 2004 22:14:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLunN-0006eR-BA; Thu, 06 May 2004 22:09:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuhw-0004ou-4R for [e-mail]; Thu, 06 May 2004 22:03:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04511 for <[e-mail]>; Thu, 6 May 2004 22:03:20 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLuht-00061R-1B for [e-mail]; Thu, 06 May 2004 22:03:21 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLugt-0005au-00 for [e-mail]; Thu, 06 May 2004 22:02:20 -0400
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BLufy-0004kT-00 for [e-mail]; Thu, 06 May 2004 22:01:22 -0400
Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i471xl326820; Thu, 6 May 2004 21:59:48 -0400 (EDT)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KJ4L78CQ; Thu, 6 May 2004 21:59:47 -0400
Received: from nortelnetworks.com (artpt5p8.us.nortel.com [47.140.52.93]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCN02TC8; Thu, 6 May 2004 21:59:46 -0400
Message-ID: <[e-mail]>
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Srikanth Chavali <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Keyur Patel <[e-mail]>
CC: idr <[e-mail]>, "John G. Scudder" <[e-mail]>
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
References: <[e-mail]> <p060204cabcc08daf6a96@[192.168.42.3]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 06 May 2004 21:59:38 -0400

Keyur/John,
                  Did you guys had a chance to read 00.txt vesion of 
this draft ? We had incorporated the views of
the Service Providers and the discussions we had with them there. If you 
did'nt let me know i will either point you to that
or send you a copy of it.  That should answer your questions as well as 
the service providers perspective on that.
In the latest versions we had trimmed that text for simplicity sake.

srikanth chavali

Keyur Patel wrote:

> Also, can you comment on as to why the "reset prefix limit" as a part 
> of local policy is not sufficient (considering this *may* be taken 
> into consideration when prefix limits have already been reached)? 
> Resetting the session is just one of the possible local actions that 
> can be taken (when the prefix limit is reached). Why just enumerate 
> one of them in the draft?
>
> -Keyur
>
> John G. Scudder wrote:
>
>> Srikanth,
>>
>> At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>>
>>> 2. If warning limit hit send the Dynamic capability (if indicator set).
>>> It serves dual purpose as warning and/or renegotiate the capabilites.
>>> It gives operators enough time to (debug errors)/(change limits).
>>
>>
>>
>> Can you comment as to why warning as a local policy is not sufficient 
>> to achieve this end?
>>
>> In particular it would be great if you could address the observation 
>> that whether generated locally or remotely, the warning is liable to 
>> be a function of the Adj-RIB size (which is known by both peers) and 
>> the prefix-limit value (which is likewise known to both peers). 
>> Furthermore the action of the router to bring the warning to the 
>> attention of the operator is inherently going to be a local matter.
>>
>> Thanks,
>>
>> --John
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr
>>
>
>
>


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA13854 for <[e-mail]>; Thu, 6 May 2004 21:59:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLubm-00038X-8b; Thu, 06 May 2004 21:57:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLua3-0002aF-6I for [e-mail]; Thu, 06 May 2004 21:55:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04086 for <[e-mail]>; Thu, 6 May 2004 21:55:11 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLua0-0002cu-5a for [e-mail]; Thu, 06 May 2004 21:55:12 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLuZ1-0002EE-00 for [e-mail]; Thu, 06 May 2004 21:54:12 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BLuYK-0001R0-00 for [e-mail]; Thu, 06 May 2004 21:53:28 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 May 2004 17:56:21 +0000
Received: from mira-sjc5-f.cisco.com (IDENT:[e-mail] [171.71.163.13]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i471qvC1010422; Thu, 6 May 2004 18:52:57 -0700 (PDT)
Received: from cisco.com (keyupate-lnx.cisco.com [128.107.163.249]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id ASC24028; Thu, 6 May 2004 18:51:11 -0700 (PDT)
Message-ID: <[e-mail]>
From: Keyur Patel <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Srikanth Chavali <[e-mail]>
CC: idr <[e-mail]>, "John G. Scudder" <[e-mail]>
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
References: <[e-mail]> <p060204cabcc08daf6a96@[192.168.42.3]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 06 May 2004 18:52:56 -0700

Also, can you comment on as to why the "reset prefix limit" as a part of 
local policy is not sufficient (considering this *may* be taken into 
consideration when prefix limits have already been reached)? Resetting 
the session is just one of the possible local actions that can be taken 
(when the prefix limit is reached). Why just enumerate one of them in 
the draft?

-Keyur

John G. Scudder wrote:

> Srikanth,
>
> At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>
>> 2. If warning limit hit send the Dynamic capability (if indicator set).
>> It serves dual purpose as warning and/or renegotiate the capabilites.
>> It gives operators enough time to (debug errors)/(change limits).
>
>
> Can you comment as to why warning as a local policy is not sufficient 
> to achieve this end?
>
> In particular it would be great if you could address the observation 
> that whether generated locally or remotely, the warning is liable to 
> be a function of the Adj-RIB size (which is known by both peers) and 
> the prefix-limit value (which is likewise known to both peers). 
> Furthermore the action of the router to bring the warning to the 
> attention of the operator is inherently going to be a local matter.
>
> Thanks,
>
> --John
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>



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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA12710 for <[e-mail]>; Thu, 6 May 2004 21:46:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuNG-000798-IR; Thu, 06 May 2004 21:42:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuJZ-0006Oj-88 for [e-mail]; Thu, 06 May 2004 21:38:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03498 for <[e-mail]>; Thu, 6 May 2004 21:38:10 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLuJW-0003UZ-F0 for [e-mail]; Thu, 06 May 2004 21:38:10 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLuIX-00033K-00 for [e-mail]; Thu, 06 May 2004 21:37:10 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BLuHa-0002Dt-00 for [e-mail]; Thu, 06 May 2004 21:36:10 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 06 May 2004 17:38:58 +0000
Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i471ZZW9001947; Thu, 6 May 2004 18:35:35 -0700 (PDT)
Received: (from achandra@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA07645; Thu, 6 May 2004 18:35:34 -0700 (PDT)
From: Chandrashekhar Appanna <[e-mail]>
To: Srikanth Chavali <[e-mail]>
Cc: [e-mail]
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 6 May 2004 18:35:34 -0700

  Dynamic capability is not intended as a signalling mechanism of
  state - that is how I see it. It is mainly to exchange high level
  session capabilities.  I would rather use a different mechanism that 
  is for the purpose of such exchanging dynamic state changes.

  To quote from the DYN-CAP draft :

   -------------
   Currently BGP capabilities [BGP-CAP] are only advertised in the OPEN
   message during the session initialization. In order to enable a new
   capability or remove an existing capability (such as an Address
   Family support [BGP-MP]), an established session may need to be
   reset, which would disrupt other services running over the session.
   -------------

  I would like to understand why the authors think that dynamic
  capabilites is an appropriate medium for this purpose.

  thanks,
  Chandra Appanna.



On Thu, May 06, 2004 at 08:23:16PM -0400, Srikanth Chavali wrote:
> I am forwarding my response to Pekka's email to clarify things..
> 
> srikanth chavali
> 
> -------- Original Message --------
> Subject: 	Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG 
> document
> Date: 	Wed, 05 May 2004 10:37:02 -0400
> From: 	Srikanth Chavali <[e-mail]>
> To: 	Pekka Savola <[e-mail]>, [e-mail]
> References: 	<[e-mail]>
> 
> 
> 
> Hi Pekka,
>              Thanks for your comments. I have replied to your model 
> related comments:
> 
> Pekka Savola wrote:
> 
> >A high-level comment:
> >---------------------
> >
> >The model seems to be so that when the receiving BGP speaker receives the
> >number of routes which exceed a warning, stop or reset limit, it sends a
> >message to inform the other router about exceeding this limit, raising a
> >warning, askit it to stop, or reset the session.
> >
> The draft does'nt say/mean/intend this.
> 
> >
> >There is another way to specify this as well.  Each router sends the 
> >other,
> >_in advance_, when opening the BGP session, their prefix limits; these
> >values are stored per peer.  The sending router checks the length of its
> >adj-ribs-out for the peer whether it exceeds any of these limits, and 
> >raises
> >warnings, stops advertising, etc. as appropriate.  (In that model, no 
> >compliant router ever exceeds these limits, even temporarily.)
> >
> The above is what the draft specifies. Please note that the exchange of 
> the prefix limit capability in the OPEN
> message (Not the Dynamic capability) achieves what you're saying above. 
> This is already specified in the draft.
> 
> So here's the mechanism in short:
> 
> 1. Exchange the capability in OPEN message. The BGP speakers note them 
> and are expected to honor them.
> 2. If warning limit hit send the Dynamic capability (if indicator set). 
> It serves dual purpose as warning and/or renegotiate the capabilites.
> It gives operators enough time to (debug errors)/(change limits).
> 3. If stop limit hit stop route advertisements. Again send Dynamic 
> capability whose purpose is as mentioned in 2.
> 
> We're working on revising the text for clarity, but if there's anything 
> specific in the text which caused mis-interpretation please
> let us know and we will address it.
> 
> Thanks
> 
> srikanth chavali
> 
> 
> 

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA09665 for <[e-mail]>; Thu, 6 May 2004 21:09:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtmV-0004sz-7W; Thu, 06 May 2004 21:04:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtgx-00039Y-5o for [e-mail]; Thu, 06 May 2004 20:58:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01577 for <[e-mail]>; Thu, 6 May 2004 20:58:16 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLtgu-0002Jd-Nr for [e-mail]; Thu, 06 May 2004 20:58:16 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLtg2-0001tc-00 for [e-mail]; Thu, 06 May 2004 20:57:22 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BLtez-00015C-00 for [e-mail]; Thu, 06 May 2004 20:56:17 -0400
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i470tjW9001491; Thu, 6 May 2004 17:55:45 -0700 (PDT)
Received: from [192.168.42.3] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA04031; Thu, 6 May 2004 20:55:43 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p060204cabcc08daf6a96@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Srikanth Chavali <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 6 May 2004 20:56:12 -0400

Srikanth,

At 8:23 PM -0400 5/6/04, Srikanth Chavali wrote:
>2. If warning limit hit send the Dynamic capability (if indicator set).
>It serves dual purpose as warning and/or renegotiate the capabilites.
>It gives operators enough time to (debug errors)/(change limits).

Can you comment as to why warning as a local policy is not sufficient 
to achieve this end?

In particular it would be great if you could address the observation 
that whether generated locally or remotely, the warning is liable to 
be a function of the Adj-RIB size (which is known by both peers) and 
the prefix-limit value (which is likewise known to both peers). 
Furthermore the action of the router to bring the warning to the 
attention of the operator is inherently going to be a local matter.

Thanks,

--John

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA08387 for <[e-mail]>; Thu, 6 May 2004 20:53:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtXz-0000S9-Cf; Thu, 06 May 2004 20:49:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtVI-0008FE-Qv for [e-mail]; Thu, 06 May 2004 20:46:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00954 for <[e-mail]>; Thu, 6 May 2004 20:46:14 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLtVG-000544-Gq for [e-mail]; Thu, 06 May 2004 20:46:14 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLtUF-0004dx-00 for [e-mail]; Thu, 06 May 2004 20:45:12 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1BLtTO-0003pu-00 for [e-mail]; Thu, 06 May 2004 20:44:18 -0400
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i470gFT21187; Thu, 6 May 2004 19:42:15 -0500 (CDT)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J83L2A0T; Thu, 6 May 2004 17:42:15 -0700
Received: from nortelnetworks.com (artpt5w7.us.nortel.com [47.140.53.69]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCN02TC4; Thu, 6 May 2004 20:42:13 -0400
Message-ID: <[e-mail]>
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Srikanth Chavali <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "John G. Scudder" <[e-mail]>, [e-mail]
Subject: Re: [Idr] signalled prefix limits -- contrasting approaches
References: <p060204bcbcc015693aed@[192.168.42.3]>
In-Reply-To: <p060204bcbcc015693aed@[192.168.42.3]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
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:

> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA07319 for <[e-mail]>; Thu, 6 May 2004 20:39:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtKP-0004og-8N; Thu, 06 May 2004 20:35:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtBv-00022C-Gq for [e-mail]; Thu, 06 May 2004 20:26:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29852 for <[e-mail]>; Thu, 6 May 2004 20:26:13 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLtBt-0004Yj-9Y for [e-mail]; Thu, 06 May 2004 20:26:13 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLtAq-00049J-00 for [e-mail]; Thu, 06 May 2004 20:25:09 -0400
Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BLt9n-0003Lq-00 for [e-mail]; Thu, 06 May 2004 20:24:03 -0400
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i470NQE25797 for <[e-mail]>; Thu, 6 May 2004 17:23:27 -0700 (PDT)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J83L2AST; Thu, 6 May 2004 17:23:26 -0700
Received: from nortelnetworks.com (artpt5w7.us.nortel.com [47.140.53.69]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCN02TC3; Thu, 6 May 2004 20:23:25 -0400
Message-ID: <[e-mail]>
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Srikanth Chavali <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document]
Content-Type: multipart/alternative; boundary="------------050101050002080905010800"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,HTML_TITLE_EMPTY autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 06 May 2004 20:23:16 -0400

This is a multi-part message in MIME format.
--------------050101050002080905010800
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I am forwarding my response to Pekka's email to clarify things..

srikanth chavali

-------- Original Message --------
Subject: 	Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG 
document
Date: 	Wed, 05 May 2004 10:37:02 -0400
From: 	Srikanth Chavali <[e-mail]>
To: 	Pekka Savola <[e-mail]>, [e-mail]
References: 	<[e-mail]>



Hi Pekka,
              Thanks for your comments. I have replied to your model 
related comments:

Pekka Savola wrote:

>A high-level comment:
>---------------------
>
>The model seems to be so that when the receiving BGP speaker receives the
>number of routes which exceed a warning, stop or reset limit, it sends a
>message to inform the other router about exceeding this limit, raising a
>warning, askit it to stop, or reset the session.
>
The draft does'nt say/mean/intend this.

>
>There is another way to specify this as well.  Each router sends the other,
>_in advance_, when opening the BGP session, their prefix limits; these
>values are stored per peer.  The sending router checks the length of its
>adj-ribs-out for the peer whether it exceeds any of these limits, and raises
>warnings, stops advertising, etc. as appropriate.  (In that model, no 
>compliant router ever exceeds these limits, even temporarily.)
>
The above is what the draft specifies. Please note that the exchange of 
the prefix limit capability in the OPEN
message (Not the Dynamic capability) achieves what you're saying above. 
This is already specified in the draft.

So here's the mechanism in short:

1. Exchange the capability in OPEN message. The BGP speakers note them 
and are expected to honor them.
2. If warning limit hit send the Dynamic capability (if indicator set). 
It serves dual purpose as warning and/or renegotiate the capabilites.
It gives operators enough time to (debug errors)/(change limits).
3. If stop limit hit stop route advertisements. Again send Dynamic 
capability whose purpose is as mentioned in 2.

We're working on revising the text for clarity, but if there's anything 
specific in the text which caused mis-interpretation please
let us know and we will address it.

Thanks

srikanth chavali




--------------050101050002080905010800
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
I am forwarding my response to Pekka's email to clarify things..<br>
<br>
srikanth chavali<br>
<br>
-------- Original Message --------
<table cellpadding="0" cellspacing="0" border="0">
  <tbody>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Subject: </th>
      <td>Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG
document</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Date: </th>
      <td>Wed, 05 May 2004 10:37:02 -0400</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">From: </th>
      <td>Srikanth Chavali <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">To: </th>
      <td>Pekka Savola <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>, <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">References: </th>
      <td><a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>Hi Pekka,
              Thanks for your comments. I have replied to your model 
related comments:

Pekka Savola wrote:

&gt;A high-level comment:
&gt;---------------------
&gt;
&gt;The model seems to be so that when the receiving BGP speaker receives the
&gt;number of routes which exceed a warning, stop or reset limit, it sends a
&gt;message to inform the other router about exceeding this limit, raising a
&gt;warning, askit it to stop, or reset the session.
&gt;
The draft does'nt say/mean/intend this.

&gt;
&gt;There is another way to specify this as well.  Each router sends the other,
&gt;_in advance_, when opening the BGP session, their prefix limits; these
&gt;values are stored per peer.  The sending router checks the length of its
&gt;adj-ribs-out for the peer whether it exceeds any of these limits, and raises
&gt;warnings, stops advertising, etc. as appropriate.  (In that model, no 
&gt;compliant router ever exceeds these limits, even temporarily.)
&gt;
The above is what the draft specifies. Please note that the exchange of 
the prefix limit capability in the OPEN
message (Not the Dynamic capability) achieves what you're saying above. 
This is already specified in the draft.

So here's the mechanism in short:

1. Exchange the capability in OPEN message. The BGP speakers note them 
and are expected to honor them.
2. If warning limit hit send the Dynamic capability (if indicator set). 
It serves dual purpose as warning and/or renegotiate the capabilites.
It gives operators enough time to (debug errors)/(change limits).
3. If stop limit hit stop route advertisements. Again send Dynamic 
capability whose purpose is as mentioned in 2.

We're working on revising the text for clarity, but if there's anything 
specific in the text which caused mis-interpretation please
let us know and we will address it.

Thanks

srikanth chavali


</pre>
</body>
</html>

--------------050101050002080905010800--


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA02388 for <[e-mail]>; Thu, 6 May 2004 19:39:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLsHZ-0000lp-Qi; Thu, 06 May 2004 19:28:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLsFu-0008SY-DR for [e-mail]; Thu, 06 May 2004 19:26:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27065 for <[e-mail]>; Thu, 6 May 2004 19:26:17 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLsFs-0002lW-Q4 for [e-mail]; Thu, 06 May 2004 19:26:16 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLsF7-0002Jk-00 for [e-mail]; Thu, 06 May 2004 19:25:30 -0400
Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BLsDw-0001lk-00 for [e-mail]; Thu, 06 May 2004 19:24:16 -0400
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 70B81747776; Thu,  6 May 2004 16:24:09 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12957-04; Thu,  6 May 2004 16:24:08 -0700 (PDT)
Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id CCBC6747774; Thu,  6 May 2004 16:24:08 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id DEE9515D3C1; Thu,  6 May 2004 16:24:07 -0700 (PDT)
To: [e-mail]
Cc: [e-mail]
Subject: Re: [Idr] signalled prefix limits -- contrasting approaches 
In-Reply-To: Message from "John G. Scudder" <[e-mail]>  of "Thu, 06 May 2004 13:03:27 EDT." <p060204bcbcc015693aed@[192.168.42.3]> 
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
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: [e-mail]
> From: "John G. Scudder" <[e-mail]>
> Subject: [Idr] signalled prefix limits -- contrasting approaches
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA23036 for <[e-mail]>; Thu, 6 May 2004 17:42:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqXD-0008Fg-09; Thu, 06 May 2004 17:36:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqJe-0002yb-UT for [e-mail]; Thu, 06 May 2004 17:22:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20490 for <[e-mail]>; Thu, 6 May 2004 17:21:59 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLqJc-00056F-Ky for [e-mail]; Thu, 06 May 2004 17:22:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLqIh-0004fV-00 for [e-mail]; Thu, 06 May 2004 17:21:03 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BLqHi-0003qT-00 for [e-mail]; Thu, 06 May 2004 17:20:02 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 May 2004 13:34:15 +0000
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i46LJTW9010626; Thu, 6 May 2004 14:19:30 -0700 (PDT)
Received: from [192.168.42.3] (dhcp-64-101-214-222.cisco.com [64.101.214.222]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA24096; Thu, 6 May 2004 17:19:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p060204c7bcc05c24ceee@[192.168.42.3]>
In-Reply-To: <p060204bfbcc01c6ee020@[192.168.42.3]>
References: <[e-mail]> <p060204bfbcc01c6ee020@[192.168.42.3]>
To: [e-mail]
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG  document
Cc: Pekka Savola <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 6 May 2004 17:19:56 -0400

At 12:59 PM -0400 5/6/04, John G. Scudder wrote:
>At 3:04 PM +0300 5/5/04, Pekka Savola wrote:
...
>>(Both models allow changing the limit on the fly with dynamic capabilities,
>>I think.)
>
>Yes.

To clarify, what we propose in draft-keyur-prefixlimit-orf-00.txt 
allows changing the limit on the fly but uses ORFs rather than 
dynamic capabilities.

--John

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03429 for <[e-mail]>; Thu, 6 May 2004 13:46:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmcN-0006SG-SU; Thu, 06 May 2004 13:25:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmKW-00013r-67 for [e-mail]; Thu, 06 May 2004 13:06:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01481 for <[e-mail]>; Thu, 6 May 2004 13:06:36 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLmKU-0005jE-Bq for [e-mail]; Thu, 06 May 2004 13:06:38 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmJ4-0005AR-00 for [e-mail]; Thu, 06 May 2004 13:05:10 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BLmHn-0004B2-00 for [e-mail]; Thu, 06 May 2004 13:03:51 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 May 2004 09:16:50 +0000
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i46H3JC1012172; Thu, 6 May 2004 10:03:20 -0700 (PDT)
Received: from [192.168.42.3] (dhcp-64-101-214-222.cisco.com [64.101.214.222]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA10321; Thu, 6 May 2004 13:03:18 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p060204bfbcc01c6ee020@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Pekka Savola <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Thu, 6 May 2004 12:59:46 -0400

At 3:04 PM +0300 5/5/04, Pekka Savola wrote:
...
>A high-level comment:
>---------------------
>
>The model seems to be so that when the receiving BGP speaker receives the
>number of routes which exceed a warning, stop or reset limit, it sends a
>message to inform the other router about exceeding this limit, raising a
>warning, askit it to stop, or reset the session.
>
>There is another way to specify this as well.  Each router sends the other,
>_in advance_, when opening the BGP session, their prefix limits; these
>values are stored per peer.  The sending router checks the length of its
>adj-ribs-out for the peer whether it exceeds any of these limits, and raises
>warnings, stops advertising, etc. as appropriate.  (In that model, no
>compliant router ever exceeds these limits, even temporarily.)

Note that this is exactly what we've proposed in 
draft-keyur-prefixlimit-orf-00.txt.

>The main difference here appears to be that the currently specified model
>requires the receiving BGP speaker to react _after_ the incident.  I.e., if
>the neighbor accidentally advertises the whole internet (instead of e.g.,
>100 prefixes), the damage has already been done, and most probably, the BGP
>session has already been reset, because the receiving BGP speaker has
>to have prefix-limits in place in any case to ensure that neighbors
>will honour the limits.
>
>So, IMHO that would argue for notifying the router about your limits in
>advance.. and if the other router does not honor them, raise and alarm, shut
>down the session, etc. on your own if needed.
>
>If you buy the latter model, the error code 5 appears to be unnecessary.
>
>(Both models allow changing the limit on the fly with dynamic capabilities,
>I think.)

Yes.

Regards,

--John

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03313 for <[e-mail]>; Thu, 6 May 2004 13:45:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmcN-0006Rr-4k; Thu, 06 May 2004 13:25:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmKV-00013p-As for [e-mail]; Thu, 06 May 2004 13:06:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01478 for <[e-mail]>; Thu, 6 May 2004 13:06:35 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLmKT-0005j9-GZ for [e-mail]; Thu, 06 May 2004 13:06:37 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmJ3-0005AI-00 for [e-mail]; Thu, 06 May 2004 13:05:10 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BLmHm-0004B2-00 for [e-mail]; Thu, 06 May 2004 13:03:51 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 06 May 2004 09:16:48 +0000
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i46H3ISu004117; Thu, 6 May 2004 10:03:19 -0700 (PDT)
Received: from [192.168.42.3] (dhcp-64-101-214-222.cisco.com [64.101.214.222]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA10315; Thu, 6 May 2004 13:03:18 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p060204bcbcc015693aed@[192.168.42.3]>
To: [e-mail]
From: "John G. Scudder" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] signalled prefix limits -- contrasting approaches
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA29205 for <[e-mail]>; Wed, 5 May 2004 11:13:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNwL-00015y-6V; Wed, 05 May 2004 11:04:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNlj-0004jF-IS for [e-mail]; Wed, 05 May 2004 10:53:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17653 for <[e-mail]>; Wed, 5 May 2004 10:53:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNlh-0005tY-0j for [e-mail]; Wed, 05 May 2004 10:53:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNkk-0005b9-00 for [e-mail]; Wed, 05 May 2004 10:52:07 -0400
Received: from web51003.mail.yahoo.com ([206.190.38.134]) by ietf-mx with smtp (Exim 4.12) id 1BLNju-0005E2-00 for [e-mail]; Wed, 05 May 2004 10:51:14 -0400
Message-ID: <[e-mail]>
Received: from [207.17.136.150] by web51003.mail.yahoo.com via HTTP; Wed, 05 May 2004 07:50:40 PDT
From: Enrico Salazar <[e-mail]>
Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt
To: Russ White <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2068401143-1083768640=:82582"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_20_30,HTML_MESSAGE autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 5 May 2004 07:50:40 -0700 (PDT)

--0-2068401143-1083768640=:82582
Content-Type: text/plain; charset=us-ascii

Russ,
 
How many is "many people" that you are referring to in your e-mail ? 
 
Enrico

Russ White <[e-mail]> wrote:

> Being able to "reconstruct large portions of overall topology" does *not*
> automatically implies being able to "reconstruct the path to each and
> every destination represented by a single prefix within an advertisement
> from the AS_PATH in that advertisement". E.g., from examining AS_PATH fo
> type AS_SEQUENCE one could infer partial information about the inter-AS
> topology.

Okay, if what many people read as the implication of this statement isn't true, and it's not critical/important to the general operation of BGP, then why are we leaving it in the draft?

:-)

Russ


__________________________________
[e-mail] CCIE <>< Grace Alone



_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr
		
---------------------------------
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs 
--0-2068401143-1083768640=:82582
Content-Type: text/html; charset=us-ascii

<DIV>Russ,</DIV>
<DIV>&nbsp;</DIV>
<DIV>How many&nbsp;is "many people" that you are referring to in your e-mail ?&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Enrico<BR><BR><B><I>Russ White &lt;[e-mail]&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>&gt; Being able to "reconstruct large portions of overall topology" does *not*<BR>&gt; automatically implies being able to "reconstruct the path to each and<BR>&gt; every destination represented by a single prefix within an advertisement<BR>&gt; from the AS_PATH in that advertisement". E.g., from examining AS_PATH fo<BR>&gt; type AS_SEQUENCE one could infer partial information about the inter-AS<BR>&gt; topology.<BR><BR>Okay, if what many people read as the implication of this statement isn't true, and it's not critical/important to the general operation of BGP, then why are we leaving it in the draft?<BR><BR>:-)<BR><BR>Russ<BR><BR><BR>__________________________________<BR>[e-mail] CCIE &lt;&gt;&lt; Grace Alone<BR><BR><BR><BR>_______________________________________________<BR>Idr mailing list<BR>[e-mail]<BR>https://www1.ietf.org/mailman/listinfo/idr</BLOCKQUOTE><!
 p>
		<hr size=1><font face=arial size=-1>Do you Yahoo!?<br><a href="http://pa.yahoo.com/*http://us.rd.yahoo.com/hotjobs/hotjobs_mail_signature_footer_textlink/evt=23983/*http://hotjobs.sweepstakes.yahoo.com/careermakeover">Win a $20,000 Career Makeover at Yahoo! HotJobs </a>
--0-2068401143-1083768640=:82582--

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA26817 for <[e-mail]>; Wed, 5 May 2004 10:44:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNWA-0007UJ-FS; Wed, 05 May 2004 10:37:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNOE-0004bK-9P for [e-mail]; Wed, 05 May 2004 10:28:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15954 for <[e-mail]>; Wed, 5 May 2004 10:28:46 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNOC-0007RZ-16 for [e-mail]; Wed, 05 May 2004 10:28:48 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNNB-0007Ap-00 for [e-mail]; Wed, 05 May 2004 10:27:46 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BLNMK-0006gn-00 for [e-mail]; Wed, 05 May 2004 10:26:52 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i45EQ7Bm057023; Wed, 5 May 2004 07:26:07 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i45EQ6J13001; Wed, 5 May 2004 07:26:06 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
cc: [e-mail], Pekka Savola <[e-mail]>, Pedro Roque Marques <[e-mail]>, Alex Zinin <[e-mail]>
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
In-Reply-To: Your message of "Tue, 04 May 2004 10:45:37 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 05 May 2004 07:26:06 -0700

Folks,

As an IDR WG co-chair it is my assessment that the IDR WG reached
a consensus to leave the following text as is.

  In the context of this document we assume that a BGP speaker
  advertises to its peers only those routes that it itself uses (in
  this context a BGP speaker is said to "use" a BGP route if it is the
  most preferred BGP route and is used in forwarding). All other cases
  are outside the scope of this document.

Yakov.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA16286 for <[e-mail]>; Wed, 5 May 2004 08:31:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLLWH-0004ud-Lg; Wed, 05 May 2004 08:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLLSw-0003ZN-Lw for [e-mail]; Wed, 05 May 2004 08:25:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09863 for <[e-mail]>; Wed, 5 May 2004 08:25:32 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLLSv-0002A6-Dh for [e-mail]; Wed, 05 May 2004 08:25:33 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLLRz-0001xf-00 for [e-mail]; Wed, 05 May 2004 08:24:36 -0400
Received: from dhcp-9-56.ripemtg.ripe.net ([193.0.9.56] helo=laptop2.kurtis.pp.se) by ietf-mx with esmtp (Exim 4.12) id 1BLLRn-0001l0-00 for [e-mail]; Wed, 05 May 2004 08:24:23 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 032013E6479; Wed,  5 May 2004 14:24:19 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05100318bcbd8be8bfa0@[192.168.0.2]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=fixed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: "Howard C. Berkowitz" <[e-mail]>, [e-mail]
From: Kurt Erik Lindqvist <[e-mail]>
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
To: Jeffrey Haas <[e-mail]>
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 5 May 2004 14:24:15 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


(I think we are getting off-topic here)

On 2004-05-04, at 20.52, Jeffrey Haas wrote:

> When routers were deployed that could handle the number of eBGP views
> at a typical exchange point, the route servers were only useful
> (for route reduction purposes) for protecting smaller boxes.  I think
> it is likely today that most exchange points will typically find boxes
> deployed that are capable of handling the relevant full or partial
> mesh that the business model that XP operates under can use.


I think route-servers are in use at IXPs simply to simplify the process 
of setting up peers. If you look look at AMS-IX/Linx type of exchanges 
with 150-200 members, and you have an open peering policy, you will 
have quite a lot of work with just configuring the peers.


But, maybe this is more a topic for grow or RIPE / Nanog etc.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQJjc8aarNKXTPFCVEQJAPQCfb23uuffqN86QZ0F1BokC+CTDI9YAoIes
8LyB4JU4is6WnZO7yPa9nhyQ
=oyZK
-----END PGP SIGNATURE-----


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA16044 for <[e-mail]>; Wed, 5 May 2004 08:28:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLLRR-0003K9-Mj; Wed, 05 May 2004 08:24:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLLNH-0002Je-3N for [e-mail]; Wed, 05 May 2004 08:19:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09725 for <[e-mail]>; Wed, 5 May 2004 08:19:41 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLLNG-0000sL-1C for [e-mail]; Wed, 05 May 2004 08:19:42 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLLMK-0000ep-00 for [e-mail]; Wed, 05 May 2004 08:18:44 -0400
Received: from dhcp-9-56.ripemtg.ripe.net ([193.0.9.56] helo=laptop2.kurtis.pp.se) by ietf-mx with esmtp (Exim 4.12) id 1BLLLf-0000RP-00 for [e-mail]; Wed, 05 May 2004 08:18:04 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id C21123E60E4; Wed,  5 May 2004 14:18:00 +0200 (CEST)
In-Reply-To: <p05100311bcbd5c8b9ee8@[192.168.0.2]>
References: <[e-mail]> <p05100311bcbd5c8b9ee8@[192.168.0.2]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=fixed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
From: Kurt Erik Lindqvist <[e-mail]>
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
To: "Howard C. Berkowitz" <[e-mail]>
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 5 May 2004 14:17:55 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 2004-05-04, at 20.04, Howard C. Berkowitz wrote:

> At 7:48 AM -0400 5/4/04, Tulip Rasputin wrote:
>> Jeff,
>>
>> [..]
>>>  All of this said, there are other small exchanges that are said to
>>>  be deploying route servers, but it sounds like these are small 
>>> regionals.
>>
>> I would not agree to this! There is this european internet exchange 
>> association (euro-ix) where
>> europe's leading ISPs connect to permit the exchange of network 
>> information. I am aware of most of
>> them using route servers (though not the ones like defined in 1863).
>
> Does Euro-IX have any documentation on the route servers it does use?

Euro-IX is an association of exchange points. Euro-IX does not operate 
either route servers or exchage points.

>
> It sounds to me as if 1863 itself may need to be made Historic, but 
> there may be a need for several new, more focused documents:
>
>     1. Use of route servers for information collection.  This might 
> actually
>        be a subset of 1863, but perhaps with updates or 
> crossreferences to
>        such things as the new data collection communities.

Agreed.

>
>     2. BCP for production use such as Euro-IX.

Sitting in the EIX meeting at the current RIPE meeting, I will bring 
this up. A lot of the Euro-IX memebers that use route-servers are 
there. I will drop the idea in here to see if there is any interest.

> As an aside, this does get into the increasingly blurred area about 
> how much the IETF RFC process is appropriate for principally 
> operational documents. There have been a number of 
> suggestions/volunteers that NANOG might provide a document function, 
> but it seems reasonably clear that the Merit people don't have room on 
> their plate for this.  Whether Euro-IX, RIPE, or RIPE-NCC are possible 
> sponsors for operational documents, or if there needs to be a specific 
> group spun off for this, is another question. Obviously, IDR alone 
> can't answer that question, but I mention it here because many 
> relevant people see this discussion.

The EIX WG at RIPE is in the process of updating the "switch wishlist" 
and Euro-IX is working on a BCP. Perhaps those are better forums for 
BCPs on route servers.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQJjbd6arNKXTPFCVEQLopQCfVtyd9MOxIy70XeSwnl13EbTCKfgAn0Gi
lNW8EU4x2risKTLYK1BFO8nD
=yTTy
-----END PGP SIGNATURE-----


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA14960 for <[e-mail]>; Wed, 5 May 2004 08:14:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLLEr-0008Vb-Kc; Wed, 05 May 2004 08:11:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLLAX-0006z7-HL for [e-mail]; Wed, 05 May 2004 08:06:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09414 for <[e-mail]>; Wed, 5 May 2004 08:06:31 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLLAW-0005ql-JI for [e-mail]; Wed, 05 May 2004 08:06:32 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLL9a-0005eI-00 for [e-mail]; Wed, 05 May 2004 08:05:35 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BLL8r-0005FF-00 for [e-mail]; Wed, 05 May 2004 08:04:50 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i45C4B122122; Wed, 5 May 2004 15:04:12 +0300
From: Pekka Savola <[e-mail]>
To: Yakov Rekhter <[e-mail]>
cc: [e-mail]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 5 May 2004 15:04:11 +0300 (EEST)

On Sun, 2 May 2004, Yakov Rekhter wrote:
> We didn't get sufficient consensus to accept 
> draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document. 
> 
> The authors of draft-chavali-bgp-prefixlimit-01.txt produced
> a new version, draft-chavali-bgp-prefixlimit-02.txt, and would
> like the IDR WG to accept this *new* version as an IDR WG document.

I've no objections to this.

FWIW, below are some comments I wrote up when reviewing the new spec.

A high-level comment:
---------------------

The model seems to be so that when the receiving BGP speaker receives the
number of routes which exceed a warning, stop or reset limit, it sends a
message to inform the other router about exceeding this limit, raising a
warning, askit it to stop, or reset the session.

There is another way to specify this as well.  Each router sends the other,
_in advance_, when opening the BGP session, their prefix limits; these
values are stored per peer.  The sending router checks the length of its
adj-ribs-out for the peer whether it exceeds any of these limits, and raises
warnings, stops advertising, etc. as appropriate.  (In that model, no 
compliant router ever exceeds these limits, even temporarily.)

The main difference here appears to be that the currently specified model
requires the receiving BGP speaker to react _after_ the incident.  I.e., if
the neighbor accidentally advertises the whole internet (instead of e.g.,
100 prefixes), the damage has already been done, and most probably, the BGP
session has already been reset, because the receiving BGP speaker has 
to have prefix-limits in place in any case to ensure that neighbors 
will honour the limits.

So, IMHO that would argue for notifying the router about your limits in
advance.. and if the other router does not honor them, raise and alarm, shut
down the session, etc. on your own if needed.

If you buy the latter model, the error code 5 appears to be unnecessary.

(Both models allow changing the limit on the fly with dynamic capabilities,
I think.)

more specifics:
---------------

   The basic functionality proposed here is for the BGP speakers to
   exchange: "warning", "stop receiving" and "disconnect" based limits.

==> s/proposed/specified/
==> s/speakers to exchange/speaker to notify/

(there is no _exchange_: each peer just _notifies_ the each other of its
limits, end of story.)

These limits are exchanged
   during the initial exchange as "open capabilities", and via the
   dynamic capability exchange during the bgp connection.

==> s/exchanged/sent/
(the rest in this section are probably fine.)

  Meaning for each of the bitwise indicated capability fields above is
   as follows:

==> the following text and different codes are difficult to read.  Would it
be possible to indent these appropriately, put in subsection, or whatever
for better readability?

   Limit Indicator (1 octet):
                                                                                                                               
   This octet can be assigned a value of 0 or 1. A value of zero means
   that the sender SHOULD NOT raise any warning. A value of 1 means the
   warning indication is necessary and SHOULD be used by the sender when
   its route advertisement equals the number of sent routes. It has the
   same meaning in all the subcodes. However, in subcode 2 it can take a
   value of 1 only. The warning mechanisms are described in the
   operation section of this draft.

==> this appears to be useless.  There is no point in sending a warning
limit unless it's supposed to warn; the same about reset.  If this spec
hasn't been implemented already, I'd suggest making this all zero, and
requiring the warning request.  If it has been implemented, just require "1"
for the (right-most?) bit always, and the rest zero.

   warning prefix limit (4 octet):
                                                                                                                               
   Number of routes sent by the BGP sender. The value for this field is
   dependent on the maximum prefix limit and SHOULD be always less than
   it.

==> s/SHOULD/MUST/ ?

   maximum prefix limit (4 octet):
                                                                                                                               
   Number of routes sent by the sender BGP speaker. When this limit is
   hit by the advertising BGP speaker it stops the route advertisement.

==> (the same around subcode 2) -- this should be more clear what "stops the
route advertisement" means.  Withdraw all the prefixes?   Stops from
advertising any new prefixes, ...., ... ?

Note that stopping advertising new prefixes could be difficult to implement
(or so I might imagine).

   It MUST be noted here that this situation will never be encountered
   if adhered to the draft. In other words this happens only during
 
==> s/adhered to the draft/this memo is followed/

4.1 Exchanging the configured prefix limits
                                                                                                                               
   BGP speakers exchange the prefix limits as an optional capability
   parameter [BGP-CAP] as described in section 4.
                                                                                                                               
 [...]
                                                                                                                               
   In figure 1 both BGP speakers A and B exchange the prefix limits
   (defined in section 4) to indicate the support for this capability.

==> again, this needs to be clearer what is exchanged.  The dynamic
capability is probably exchanged.  The routers notify those which support
the capability of their prefix limits.  The notified routers may act on them
if they want.  The notified routers don't have to send you their prefix
limits (if they have them).
==> (similar later on in the section)

7. References

==> need to be split to normative and informative.

8. IANA Considerations
                                                                                                                               
   This document uses a new capability type for the support of prefix
   limits and the corresponding NOTIFICATION code along with the sub-
   codes for non-support. This must be assigned by IANA.

==> this section should be much more clearer on what should be assigned and
based on which which section of the document (e.g., possibly in a table
form).

10. Full Copyright Statement
                                                                                                                               
   Copyright (C) The Internet Society (2000).  All Rights Reserved.

==> a bit out of data year.

==> include the IPR boilerplate.

11. Author's Addresses:

==> s/'s/s'/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA13591 for <[e-mail]>; Wed, 5 May 2004 07:57:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLKud-0002oY-IO; Wed, 05 May 2004 07:50:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLKt4-0002Gm-Nx for [e-mail]; Wed, 05 May 2004 07:48:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08708 for <[e-mail]>; Wed, 5 May 2004 07:48:29 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLKt3-0001t2-Sj for [e-mail]; Wed, 05 May 2004 07:48:29 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLKs7-0001fJ-00 for [e-mail]; Wed, 05 May 2004 07:47:32 -0400
Received: from hibernia.jakma.org ([212.17.55.49]) by ietf-mx with esmtp (Exim 4.12) id 1BLKrB-0001QZ-00 for [e-mail]; Wed, 05 May 2004 07:46:33 -0400
Received: from fogarty.jakma.org (IDENT:[e-mail] [192.168.0.4]) by hibernia.jakma.org (8.12.10/8.12.10) with ESMTP id i45BkTNY014502; Wed, 5 May 2004 12:46:30 +0100
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Pekka Savola <[e-mail]>
cc: [e-mail]
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 5 May 2004 12:46:30 +0100 (IST)

On Mon, 3 May 2004, Pekka Savola wrote:

> Hi,
> 
> Should draft-ietf-idr-rfc2796bis-00.txt or some other document also
> make RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh
> routing") historic?

Is RFC1863 not historic anyway by virtue of utter lack of support?
TTBOMK there are no widely deployed BGP implementations with support
for client side of 1863, nor is there ever likely to be AFAICT.

> IDRP is at least extict, but are BGP route servers useful for the
> replacement of a full mesh (anymore/at all)?

Chicken and egg possibly. There is no good deployable route-server
solution other than the path-selecting type, which requires knowledge
of client policy and hence is operationally expensive for, eg, IXes
with many clients with diverse policy. 

That doesnt mean there would not be interest in future in some kind 
of better BGP route-server or even just 'connection concentrator' 
solution.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
	warning: do not ever send email to [e-mail]
Fortune:
It'll be a nice world if they ever get it finished.

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA24924 for <[e-mail]>; Wed, 5 May 2004 03:59:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLHBH-0001mk-4M; Wed, 05 May 2004 03:51:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLH7r-0000yA-RH for [e-mail]; Wed, 05 May 2004 03:47:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27658 for <[e-mail]>; Wed, 5 May 2004 03:47:29 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLH7p-0006kI-95 for [e-mail]; Wed, 05 May 2004 03:47:29 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLH6x-0006ZM-00 for [e-mail]; Wed, 05 May 2004 03:46:36 -0400
Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BLH6W-0006Mx-00 for [e-mail]; Wed, 05 May 2004 03:46:09 -0400
Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <HSJGMAK3>; Wed, 5 May 2004 08:45:45 +0100
Message-ID: <[e-mail]>
From: Michael Dell <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG doc ument
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Wed, 5 May 2004 08:45:26 +0100

This looks like a useful extension, and we support its adoption as an IDR WG
document.  I would expect this to be something which the operator could
enable/disable as required.

Mike Dell
Networking Protocols Group
Data Connection Ltd
Tel: [phone]
Fax: [phone]
E-mail: [e-mail]
Web: http://www.dataconnection.com


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]]
Sent: 30 April 2004 18:22
To: [e-mail]
Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG
document


Folks

We receive a request to accept draft-chen-bgp-avoid-transition-01.txt
as an IDR WG document. Please comment to the list. The deadline
for comments is May 14, 2004. 

Yakov.
------- Forwarded Message

Date:    Wed, 28 Apr 2004 10:13:29 -0700
From:    Enke Chen <[e-mail]>
To:      [e-mail], [e-mail]
cc:      [e-mail]
Subject: draft-chen-bgp-avoid-transition-01.txt

Hi, Yakov and Sue:

I would like to request that the draft
<draft-chen-bgp-avoid-transition-01.txt>
be accepted as an IDR WG document. The draft was presented previosuly at an
IDR meeting. The algorithm described in the draft has been deployed for
several
years.

Thanks. -- Enke

- ------- Forwarded Message

Message-Id: <[e-mail]>
To: IETF-Announce: ;
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt
Date: Tue, 20 Jan 2004 10:04:35 -0500

- - --NextPart

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


	Title		: Avoid BGP Best Path Transition from One External
to A
nother
	Author(s)	: E. Chen, S. Sangli
	Filename	: draft-chen-bgp-avoid-transition-01.txt
	Pages		: 5
	Date		: 2004-1-19
	
In this document we propose an algorithm that would help improve the
overall network stability by avoiding BGP best path transition from
one external to another (under certain conditions)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt


- ------- End of Forwarded Message


------- End of Forwarded Message


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

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA11160 for <[e-mail]>; Tue, 4 May 2004 18:51:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL8hl-0006AJ-Nz; Tue, 04 May 2004 18:48:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL8a1-0004J1-1X for [e-mail]; Tue, 04 May 2004 18:40:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04888 for <[e-mail]>; Tue, 4 May 2004 18:39:56 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL8Zx-0003Lm-Vl for [e-mail]; Tue, 04 May 2004 18:39:58 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL8ZD-0003Eh-00 for [e-mail]; Tue, 04 May 2004 18:39:12 -0400
Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx with esmtp (Exim 4.12) id 1BL8YP-00035j-00 for [e-mail]; Tue, 04 May 2004 18:38:21 -0400
Received: by mailhost.jlc.net (Postfix, from userid 104) id C8577E05DB; Tue,  4 May 2004 18:38:13 -0400 (EDT)
From: John Leslie <[e-mail]>
To: Russ White <[e-mail]>
Cc: Enrico Salazar <[e-mail]>, Cheng-Yin Lee <[e-mail]>, Alex Zinin <[e-mail]>, [e-mail]
Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt
Message-ID: <20040504223813.GC94158@verdi>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR  autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 18:38:13 -0400

Russ White <[e-mail]> wrote:
> To: Enrico Salazar <[e-mail]>
> 
>> Being able to "reconstruct large portions of overall topology" does *not*
>> automatically implies being able to "reconstruct the path to each and
>> every destination represented by a single prefix within an advertisement
>> from the AS_PATH in that advertisement". E.g., from examining AS_PATH fo
>> type AS_SEQUENCE one could infer partial information about the inter-AS
>> topology.
> 
> Okay, if what many people read as the implication of this statement isn't
> true, and it's not critical/important to the general operation of BGP, then
> why are we leaving it in the draft?

   I've always assumed this was an attempt to distinguish BGP -- a true
distance-vector protocol -- from all the "distance-scalar" protocols
incorrectly called "distance-vector" protocols.

   Unlike the distance-scalar protocols, BGP allows us to reconstruct
what I'd call "likely actual paths" to be taken by packets sent to
different BGP neighbors, and make policy decision based on those
likely paths.

   Personally, I'd be much happier with language which at least hinted
at this actual difference; but I gave up trying to change this text
long before the last-call started...

--
John Leslie <[e-mail]>

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA26600 for <[e-mail]>; Tue, 4 May 2004 15:48:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL5ph-0002eY-TW; Tue, 04 May 2004 15:44:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL5ig-0000me-LX for [e-mail]; Tue, 04 May 2004 15:36:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24527 for <[e-mail]>; Tue, 4 May 2004 15:36:44 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL5if-00053e-A5 for [e-mail]; Tue, 04 May 2004 15:36:45 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5hm-0004xo-00 for [e-mail]; Tue, 04 May 2004 15:35:51 -0400
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BL5gs-0004rO-00 for [e-mail]; Tue, 04 May 2004 15:34:54 -0400
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BL5gs-000Cms-ES for [e-mail]; Tue, 04 May 2004 19:34:54 +0000
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME  autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Idr] Fwd: Updated version posted: draft-kompella-zinin-early-allocation-01.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 12:34:52 -0700

FYI
-- 
Alex
http://www.psg.com/~zinin/

This is a forwarded message
From: Alex Zinin <[e-mail]>
To: [e-mail]
Cc: 
Date: Monday, May 3, 2004, 6:29:39 PM
Subject: Updated version posted: draft-kompella-zinin-early-allocation-01.txt

===8<==============Original message text===============
Folks-

 Kireeti and I updated the draft based on the comments we got via e-mail and at
 the meeting in Seoul. Please check the new rev. We will be asking Bill to Last
 Call the document within a few weeks. Send comments to [e-mail],
 please.

 The draft is available at:

   http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-01.txt

 For your convenience, the htmldiff is available at:
 
   http://www.psg.com/~zinin/ietf/draft-kompella-zinin-early-allocation-00-01-diff.html
 
 Abstract from the draft:

   This memo discusses earlier allocation of code points by IANA as a
   remedy to the problem created by the "Standards Action" IANA policy
   for protocols where, by the IETF process, implementation and
   deployment experience is desired or required prior to publication.

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


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

===8<===========End of original message text===========


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA25022 for <[e-mail]>; Tue, 4 May 2004 15:27:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL5TQ-0005gv-Uq; Tue, 04 May 2004 15:21:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL5Ni-0003Ig-FM for [e-mail]; Tue, 04 May 2004 15:15:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22831 for <[e-mail]>; Tue, 4 May 2004 15:15:04 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL5Nh-0002Z6-67 for [e-mail]; Tue, 04 May 2004 15:15:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5Mn-0002QY-00 for [e-mail]; Tue, 04 May 2004 15:14:10 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BL5MA-0002HW-00 for [e-mail]; Tue, 04 May 2004 15:13:31 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i44JCBaL025166; Tue, 4 May 2004 15:12:11 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Howard C. Berkowitz" <[e-mail]>
cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)] 
In-reply-to: Your message of "Tue, 04 May 2004 14:13:40 EDT." <p05100318bcbd8be8bfa0@[192.168.0.2]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 04 May 2004 15:12:11 -0400

In message <p05100318bcbd8be8bfa0@[192.168.0.2]>, "Howard C. Berkowitz" writes:
> At 11:18 AM -0400 5/4/04, Jeffrey Haas wrote:
> >On Tue, May 04, 2004 at 05:58:11PM +0300, Pekka Savola wrote:
> >>  Route collectors or route servers used for other debugging purposes
> >>  are an entirely different thing from route servers used to replace
> >>  iBGP mesh, right?
> >
> >And an even stronger distinction:
> >
> >If you're going to do iBGP mesh, a route reflector is usually a better
> >solution.
> >
> >Route servers are generally designed to serve as route proxies to
> >create view-based policy.  At the least, this is the design for RSd.
> 
> I hope this isn't getting too far afield, but let me share a concept 
> that I use in teaching, and, to some extent, we considered in the 
> BMWG BGP convergence work.  This idea grew out of the Internet Growth 
> panel that Sue, Frank and I did at the Stockholm ISOC.
> 
> We have real-world problems with the scalability of actual BGP 
> routers (as distinct from the scalability of the overall routing 
> system).  One of the limiting factors is the number of peering 
> sessions per box.
> 
> I argue that we have several techniques for improving scaling by 
> reducing the number of sessions.  Route reflection is an obvious 
> technique for iBGP scalability.  I tend to think of confederations in 
> two ways:  an adjunct to iBGP scalability, but also a way to 
> implement finer-grained policies.  I've tended to use RR's for 
> service provider implementations, but more often have used 
> confederations for enterprises with complex multihoming and internal 
> flow policies.
> 
> In my experience, newbies better understand all of the scalability 
> methods if one adds the idea of the "classic" or "historic" RsD-style 
> route server as an _e_BGP scalability technique. SO to come back to 
> Jeff's comment, a route server replaces/reduces full eBGP mesh at 
> exchange points.


We need more di-lithium crystals captain.  Or whatever they make those
processors out of these days.

Multiple processors responsible for the adjacency processing has
helped the "too many peers" problem in some routers.

So what does any of this have to do with RFC1863?  John Scudder
summarized things quite well.

Curtis


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23089 for <[e-mail]>; Tue, 4 May 2004 15:03:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL57C-00076h-4v; Tue, 04 May 2004 14:58:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL549-0006Mc-Kt for [e-mail]; Tue, 04 May 2004 14:54:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20785 for <[e-mail]>; Tue, 4 May 2004 14:54:50 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL546-0000Mz-Qo for [e-mail]; Tue, 04 May 2004 14:54:50 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL53F-0000Ef-00 for [e-mail]; Tue, 04 May 2004 14:53:58 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BL52J-0007lW-00 for [e-mail]; Tue, 04 May 2004 14:52:59 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B3B962D4826; Tue,  4 May 2004 14:52:29 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 62758-01-48; Tue,  4 May 2004 14:52:18 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 35DB42D4804; Tue,  4 May 2004 14:52:18 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i44IqIv05317; Tue, 4 May 2004 14:52:18 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: "Howard C. Berkowitz" <[e-mail]>
Cc: [e-mail]
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05100318bcbd8be8bfa0@[192.168.0.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05100318bcbd8be8bfa0@[192.168.0.2]>; from [e-mail] on Tue, May 04, 2004 at 02:13:40PM -0400
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 14:52:18 -0400

Note: I haven't been doing this stuff anywhere near as long as some
of the members of this forum.  This said, here is my opinion based
on some second and third hand stories.

On Tue, May 04, 2004 at 02:13:40PM -0400, Howard C. Berkowitz wrote:
> In my experience, newbies better understand all of the scalability 
> methods if one adds the idea of the "classic" or "historic" RsD-style 
> route server as an _e_BGP scalability technique. SO to come back to 
> Jeff's comment, a route server replaces/reduces full eBGP mesh at 
> exchange points.

In the beginning of the Internet, route servers served a useful role
in reducing the routing table traffic load on the hosts at an exchange
point to levels within the capacity available to the boxes at the time.

Apparently, the window of time where this was necessary was 
"reasonably small".  

When routers were deployed that could handle the number of eBGP views
at a typical exchange point, the route servers were only useful 
(for route reduction purposes) for protecting smaller boxes.  I think
it is likely today that most exchange points will typically find boxes
deployed that are capable of handling the relevant full or partial
mesh that the business model that XP operates under can use.

The route servers often caused more problems than they were worth in
environments where reachability to the route server didn't imply
reachability to the actual router advertising the routes.  

In the era when boxes are thought to be capable of handling a pretty
serious routing load, the route server model excels at one thing - 
proxying policy.  "I ask for X set of destinations, I only want to
send you Y destinations".  Configure it in a database, run RtConfig
and let it rip.

Nothing stops a bgp speaker from doing similar things with RtConfig
at their edges.  However, when you start doing it for a reasonable
number of peers, your policy tends to get huge.  Some boxes deal
with huge policy better than others.

If you wish to contemplate how route servers scale, remember that
a route server is much the same case as a 2547 PE router.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA20728 for <[e-mail]>; Tue, 4 May 2004 14:34:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4cG-0006kA-1i; Tue, 04 May 2004 14:26:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4SR-0003zf-J6 for [e-mail]; Tue, 04 May 2004 14:15:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17208 for <[e-mail]>; Tue, 4 May 2004 14:15:52 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL4SP-0003Fp-4I for [e-mail]; Tue, 04 May 2004 14:15:53 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4RZ-00039f-00 for [e-mail]; Tue, 04 May 2004 14:15:01 -0400
Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx with esmtp (Exim 4.12) id 1BL4Qn-00030S-00 for [e-mail]; Tue, 04 May 2004 14:14:13 -0400
Received: from [192.168.0.2] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (rwcrmhc13) with ESMTP id <20040504181342015009b2hle> (Authid: hcb8); Tue, 4 May 2004 18:13:42 +0000
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05100318bcbd8be8bfa0@[192.168.0.2]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
To: [e-mail]
From: "Howard C. Berkowitz" <[e-mail]>
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 14:13:40 -0400

At 11:18 AM -0400 5/4/04, Jeffrey Haas wrote:
>On Tue, May 04, 2004 at 05:58:11PM +0300, Pekka Savola wrote:
>>  Route collectors or route servers used for other debugging purposes
>>  are an entirely different thing from route servers used to replace
>>  iBGP mesh, right?
>
>And an even stronger distinction:
>
>If you're going to do iBGP mesh, a route reflector is usually a better
>solution.
>
>Route servers are generally designed to serve as route proxies to
>create view-based policy.  At the least, this is the design for RSd.

I hope this isn't getting too far afield, but let me share a concept 
that I use in teaching, and, to some extent, we considered in the 
BMWG BGP convergence work.  This idea grew out of the Internet Growth 
panel that Sue, Frank and I did at the Stockholm ISOC.

We have real-world problems with the scalability of actual BGP 
routers (as distinct from the scalability of the overall routing 
system).  One of the limiting factors is the number of peering 
sessions per box.

I argue that we have several techniques for improving scaling by 
reducing the number of sessions.  Route reflection is an obvious 
technique for iBGP scalability.  I tend to think of confederations in 
two ways:  an adjunct to iBGP scalability, but also a way to 
implement finer-grained policies.  I've tended to use RR's for 
service provider implementations, but more often have used 
confederations for enterprises with complex multihoming and internal 
flow policies.

In my experience, newbies better understand all of the scalability 
methods if one adds the idea of the "classic" or "historic" RsD-style 
route server as an _e_BGP scalability technique. SO to come back to 
Jeff's comment, a route server replaces/reduces full eBGP mesh at 
exchange points.


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA20026 for <[e-mail]>; Tue, 4 May 2004 14:25:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4Qf-0003MG-4V; Tue, 04 May 2004 14:14:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4Jq-0000xC-B0 for [e-mail]; Tue, 04 May 2004 14:07:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16507 for <[e-mail]>; Tue, 4 May 2004 14:06:59 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL4Jn-0002Fi-R7 for [e-mail]; Tue, 04 May 2004 14:06:59 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4Ir-00028S-00 for [e-mail]; Tue, 04 May 2004 14:06:02 -0400
Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1BL4IG-00020N-00 for [e-mail]; Tue, 04 May 2004 14:05:24 -0400
Received: from [192.168.0.2] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (sccrmhc11) with ESMTP id <2004050418044401100d9vpbe> (Authid: hcb8); Tue, 4 May 2004 18:04:50 +0000
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05100311bcbd5c8b9ee8@[192.168.0.2]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: [e-mail]
From: "Howard C. Berkowitz" <[e-mail]>
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 14:04:43 -0400

At 7:48 AM -0400 5/4/04, Tulip Rasputin wrote:
>Jeff,
>
>[..]
>>  All of this said, there are other small exchanges that are said to
>>  be deploying route servers, but it sounds like these are small regionals.
>
>I would not agree to this! There is this european internet exchange 
>association (euro-ix) where
>europe's leading ISPs connect to permit the exchange of network 
>information. I am aware of most of
>them using route servers (though not the ones like defined in 1863).

Does Euro-IX have any documentation on the route servers it does use?

It sounds to me as if 1863 itself may need to be made Historic, but 
there may be a need for several new, more focused documents:

     1. Use of route servers for information collection.  This might actually
        be a subset of 1863, but perhaps with updates or crossreferences to
        such things as the new data collection communities.

     2. BCP for production use such as Euro-IX.

     3. Possibly something informational about L3 exchanges where
        an exchange-operated router is there primarily for routing
        information exchange. ISTR a Cisco workshop describing such
        techniques as a first step to high-capacity L2 exchanges, and
        I've seen this done both in small North American exchanges and
        reports on Asia-Pacific initial exchanges.

As an aside, this does get into the increasingly blurred area about 
how much the IETF RFC process is appropriate for principally 
operational documents. There have been a number of 
suggestions/volunteers that NANOG might provide a document function, 
but it seems reasonably clear that the Merit people don't have room 
on their plate for this.  Whether Euro-IX, RIPE, or RIPE-NCC are 
possible sponsors for operational documents, or if there needs to be 
a specific group spun off for this, is another question. Obviously, 
IDR alone can't answer that question, but I mention it here because 
many relevant people see this discussion.

>
>>  > The
>>  > fact that they did not get a wide vendor support is bug not a feature.
>>
>>  Please note that RFC 1863 doesn't so much define a route server as
>>  it does a route-reflector style mechanism for route servers.  This is
>>  the bit that didn't get wide deployment.
>
>Am sure IXPs would love to have better ways to implement route 
>servers. If there are any IXPs
>here, they could probably second me!
>
>>  IMO, 1863 is a bit more complicated than what we would want these
>>  days given modern route reflection techniques.  If a need exists to
>>  allow multiple views to be passed around in BGP there are better ways
>>  to go about it.
>
>Like how?
>
>Rasputin.
>
>
>______________________________________________________________________
>Post your free ad now! http://personals.yahoo.ca
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr


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


Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA18449 for <[e-mail]>; Tue, 4 May 2004 14:05:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4B8-0006Xd-QR; Tue, 04 May 2004 13:58:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL41H-0001h8-9b for [e-mail]; Tue, 04 May 2004 13:47:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15505 for <[e-mail]>; Tue, 4 May 2004 13:47:48 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL41E-0000Fk-Vx for [e-mail]; Tue, 04 May 2004 13:47:49 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL40M-0000AE-00 for [e-mail]; Tue, 04 May 2004 13:46:55 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BL3zt-000045-00 for [e-mail]; Tue, 04 May 2004 13:46:25 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BC9432D483A for <[e-mail]>; Tue,  4 May 2004 13:45:53 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 61410-01-15 for <[e-mail]>; Tue,  4 May 2004 13:45:41 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3BD712D4826 for <[e-mail]>; Tue,  4 May 2004 13:45:41 -0400 (EDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-00.txt
Message-ID: <[e-mail]>
Thread-Topic: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-00.txt
Thread-Index: AcQilB0f86b7IQfaS8SsYSFs0ujX5gAQ5qdg
From: "Susan Hares" <[e-mail]>
To: "Alex Zinin" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 13:45:41 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA18449

Alex:

I'm catching up with old mail that I didn't respond to:

	On section 1 - oops, I'll fix that to match the draft
	On section 1.2 - oops, will fix tonight.
	On section 1.4 - I've got to query the implementers. 
	On section 1.5.2 - I'll query Laurel.
	
	RFC 2119 - we need to at least note that that was the context
		     of the messages.  Could you send text that you'd like
			that indicates that message. 

Thanks for all the great comments.

Sue
 
-----Original Message-----
From: Alex Zinin [mailto:[e-mail]]
Sent: Wednesday, April 14, 2004 10:42 PM
To: [e-mail]
Subject: [Idr] AD-review comments on
draft-ietf-idr-bgp-implementation-00.txt


Seems like this is out of context.

>     RFC 1771 in alignment with the deployments of the BGP-4 protocols.   
>     The changes with RFC 1771 are listed in the appendix A of[BGP4].   
>     BGP-4 as deployed in the Internet encompasses both this base 
>     specification and additional specifications such as TCP MD5 
>     [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations   
>     [RFC3065], and BGP Route Refresh [RFC 2918].  
>             
>     BGP as a widely deployed cornerstone of Internet technology 
>     continues to add additional functionality as the needs within the 
>     Internet require. This survey had 259 detailed questions on the 
>     compliances with the standard.  3 implementers (Cisco, Laurel, 
>     NextHop) sent in implementation reports.  Sections X - Y provides 
>     the compilation of those results. 
> 

[snip] 
      
>     X implementers who responded below indicating inter-operability with 
>     other implementations.  Of these X implementations, Y also indicated 
>     the length of the survey was as problem. The editor recommends that 
>     other methods, such as enlisting existing testing vendors be 
>     employed to gather more implementation report. 
>      
>     Section Z provides the quick survey results on inter-operability.  
>     
>  
>  
> Hares & Retana          Expires - August 2004                [Page 3] 
> 
> 
> 
> 
>                  draft-ietf-idr-bgp-implementation-00    February 2004 
>  
>  

X, Y, and Z need to be filled out... ;)

> 1.2 Full Survey result summary 
>      
>     Significant Differences 
>       
>     All 259 survey points had two "y" or "y" and "O" except the 
>     following: 

At this point of the document, it is not clear what "y" and "0" are.

>       

Generally, if we don't have at least two implementations for a specific feature,
it can't stay in the spec. The granularity of the BGP implementation report
is finer than on a per-feature basis, but we still need to see if the spec needs
to be fixed accordingly. More specific comments below:

>       MUST - Question 214 
>        
>       Question 214 about aggregation of  routes. section 9.1.4 had a "N" 
>       response from 3 implementers indicating that they install both 
>       routes, and 1 yes. 

when I look at section 2.43.214, I see:

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y 
       Laurel  Y/N/O/Comments: Y 
       NextHop Y/N/O/Comments: Y 

wrong section?

>       SHALL NOT - Question 228, regarding section 9.2.2.2 
>        
>       Three vendors (Alcatel, Cisco, Laurel), answered "N" to shall not 
>       (meaning they did).  One vendor (NextHop) indicate "y" matching 
>       the specification. 
>        
>         text: Routes that have different MULTI_EXIT_DISC attribute SHALL 
>         NOT be aggregated. 

If this is considered to be important for protocol correctness, then the WG
may consider softening the requirements language and changing it to "SHOULD
NOT"--apparently some implementers found that under certain circumstances
such routes still need to be aggregated.

>       SHOULD - 2 in appendix F (questions 257, 258)
>        
>       Three vendors said no, one vendor said yes to question 257.  All 
>       four vendors indicated no to question 258. (Please note that 
>       Appendix F is an optional text section) 
>         
>        Text: section F.2 - A BGP speaker which needs to withdraw a 
>        destination and send an update about a more specific or less  
>        specific route SHOULD combine them into the same UPDATE message.  
>         
>        Text: Section F.6: The last instance (rightmost occurrence) of 
>        that AS number is kept.

Assuming that the appendices are not a normative part of the spec, the
2119 language should not be used there.

...
> 1.4 Implementations and interoperability
>     
>    Short informal summary of implementers reporting implementations and 
>    inter-operability 
>      
>      [This section will be added later but will have the format below ] 
>
>                     Alcatel Cisco Laurel  NextHop  
>        Alcatel                                 
>        Cisco                                   
>        Laurel                                                   
>        NextHop                                        

the above table needs to be filled out.

> 1.5 BGP Implementation Identification

This section does not specify the origin of code

>    1.5.0 Alcatel 
>     
>    1.5.1 Cisco 
>    Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S 
>    Date: 11/26/2003 
>     
>    1.5.2 Laurel 
>     
>    1.5.3 NextHop Technologies 
>    Implementation Name/Version: Gated NGC 2.0, 2.2 
>    Date: January 2004  
>  
>  
> Hares & Retana          Expires - August 2004                [Page 5] 
> 
> 
> 
> 
>                  draft-ietf-idr-bgp-implementation-00    February 2004 
>  
>  
>     
> 2. BGP4 Implementation Report 
>     
>    For every item listed, the respondents indicated whether their 
>    implementation supports the Functionality/Description or not (Y/N) 
>    according to the RFC2119 [3] language indicated.

"according to the RFC 2119" should probably be removed. The implementation
either decides to support something the 2119 language prescribes in some form or
it doesn't.

> Any respondent 
>    comments are included.  If appropriate, the respondents indicated 
>    with O the fact that the support is neither Y/N (an alternate 
>    behavior, for example). Refer to the appropriate sections in the 
>    latest BGP-4 ID [4] for additional details. 



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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA07707 for <[e-mail]>; Tue, 4 May 2004 11:56:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2F7-00021V-Cl; Tue, 04 May 2004 11:54:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2Cn-0001iY-1i for [e-mail]; Tue, 04 May 2004 11:51:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09521 for <[e-mail]>; Tue, 4 May 2004 11:51:34 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL2Cl-00050O-Rx for [e-mail]; Tue, 04 May 2004 11:51:35 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2Bm-0004ua-00 for [e-mail]; Tue, 04 May 2004 11:50:35 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BL2Ar-0004n0-00 for [e-mail]; Tue, 04 May 2004 11:49:38 -0400
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 04 May 2004 08:49:21 -0700
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i44Fn30Q005672 for <[e-mail]>; Tue, 4 May 2004 08:49:04 -0700 (PDT)
Received: from [192.168.42.3] (dhcp-64-101-214-222.cisco.com [64.101.214.222]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA22442 for <[e-mail]>; Tue, 4 May 2004 11:49:03 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p060204a3bcbd646fdef7@[192.168.42.3]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: [e-mail]
From: "John G. Scudder" <[e-mail]>
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 11:49:29 -0400

Jeff makes a very good point that bears emphasis:

At 11:37 PM -0400 5/3/04, Jeffrey Haas wrote:
>Please note that RFC 1863 doesn't so much define a route server as
>it does a route-reflector style mechanism for route servers.  This is
>the bit that didn't get wide deployment.

For those who haven't gone and looked at 1863 before joining the 
conversation, here is the abstract.  In short, as Jeff has been 
saying, 1863 is an alternative to route reflectors:

    This document describes the use and detailed design of Route Servers
    for dissemination of routing information among BGP/IDRP speaking
    routers.

    The intention of the proposed technique is to reduce overhead and
    management complexity of maintaining numerous direct BGP/IDRP
    sessions which otherwise might be required or desired among routers
    within a single routing domain as well as among routers in different
    domains that are connected to a common switched fabric (e.g. an ATM
    cloud).

While a discussion about other things that are also called "route 
servers" may be interesting, I don't think it's germane to Pekka's 
original question which was whether RFC 1863 in specific should be 
moved to "historical."

I think it should be.  As far as I know there are no extant 
implementations and it's never been (widely? at all?) deployed.  That 
fits pretty well with my understanding of "historical."

I think a good reason not to move it to historical would be if the 
1863 mechanisms in specific are needed/wanted for some current use. 
But discussions of any old thing that happens to be called a "route 
server" misses the point of the original question.

--John

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA05010 for <[e-mail]>; Tue, 4 May 2004 11:29:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1o1-0003JE-OW; Tue, 04 May 2004 11:26:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1j1-0001sJ-R6 for [e-mail]; Tue, 04 May 2004 11:20:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07827 for <[e-mail]>; Tue, 4 May 2004 11:20:49 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL1j0-0002V0-MP for [e-mail]; Tue, 04 May 2004 11:20:50 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1hz-0002Qb-00 for [e-mail]; Tue, 04 May 2004 11:19:48 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BL1hP-0002L3-00 for [e-mail]; Tue, 04 May 2004 11:19:11 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8E2C42D4879; Tue,  4 May 2004 11:18:41 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 55586-01-99; Tue,  4 May 2004 11:18:30 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3608C2D4869; Tue,  4 May 2004 11:18:30 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i44FIUN04841; Tue, 4 May 2004 11:18:30 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Pekka Savola <[e-mail]>
Cc: Tulip Rasputin <[e-mail]>, [e-mail]
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, May 04, 2004 at 05:58:11PM +0300
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 11:18:30 -0400

On Tue, May 04, 2004 at 05:58:11PM +0300, Pekka Savola wrote:
> Route collectors or route servers used for other debugging purposes 
> are an entirely different thing from route servers used to replace 
> iBGP mesh, right?

And an even stronger distinction:

If you're going to do iBGP mesh, a route reflector is usually a better
solution.

Route servers are generally designed to serve as route proxies to
create view-based policy.  At the least, this is the design for RSd.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA04785 for <[e-mail]>; Tue, 4 May 2004 11:27:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1m5-0002V3-3M; Tue, 04 May 2004 11:24:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1eB-0000f4-2y for [e-mail]; Tue, 04 May 2004 11:15:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07627 for <[e-mail]>; Tue, 4 May 2004 11:15:48 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL1eA-00027D-5Z for [e-mail]; Tue, 04 May 2004 11:15:50 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1dI-00022S-00 for [e-mail]; Tue, 04 May 2004 11:14:56 -0400
Received: from dhcp-9-56.ripemtg.ripe.net ([193.0.9.56] helo=laptop2.kurtis.pp.se) by ietf-mx with esmtp (Exim 4.12) id 1BL1ca-0001xB-00 for [e-mail]; Tue, 04 May 2004 11:14:12 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id B94113DFD70; Tue,  4 May 2004 17:14:10 +0200 (CEST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=fixed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
From: Kurt Erik Lindqvist <[e-mail]>
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
To: Tulip Rasputin <[e-mail]>
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 17:14:05 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> All of this said, there are other small exchanges that are said to
>> be deploying route servers, but it sounds like these are small 
>> regionals.
>
> I would not agree to this! There is this european internet exchange 
> association (euro-ix) where
> europe's leading ISPs connect to permit the exchange of network 
> information. I am aware of most of
> them using route servers (though not the ones like defined in 1863).

As the current chair of Euro-IX...

yes there is a lot of interest in route servers and I think the two 
most widely used are at two out of the four largest IXPs in Europe.


>> it does a route-reflector style mechanism for route servers.  This is
>> the bit that didn't get wide deployment.
>
> Am sure IXPs would love to have better ways to implement route 
> servers. If there are any IXPs
> here, they could probably second me!

I think 'it depends'. I don't think IXPs per se care, the customers of 
the IXPs do and the IXPs try to serve them as best as possible. And I 
do think there is need for it, and also a need for updated 
documentation.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQJezQKarNKXTPFCVEQIqggCdG+mYAze2an1maM1Q+BagZ9jh3iUAoLzg
QWBWTgN/8AGN1pCxAVZaSDsV
=Uz3Z
-----END PGP SIGNATURE-----


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03071 for <[e-mail]>; Tue, 4 May 2004 11:10:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1Vd-0006cC-CH; Tue, 04 May 2004 11:07:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1PX-0004wl-8P for [e-mail]; Tue, 04 May 2004 11:00:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06658 for <[e-mail]>; Tue, 4 May 2004 11:00:39 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL1PU-0000mJ-N2 for [e-mail]; Tue, 04 May 2004 11:00:40 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1Oe-0000hp-00 for [e-mail]; Tue, 04 May 2004 10:59:49 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BL1Nf-0000aT-00 for [e-mail]; Tue, 04 May 2004 10:58:47 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i44EwBN04384; Tue, 4 May 2004 17:58:11 +0300
From: Pekka Savola <[e-mail]>
To: Tulip Rasputin <[e-mail]>
cc: [e-mail]
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 17:58:11 +0300 (EEST)

On Tue, 4 May 2004, Tulip Rasputin wrote:
> [..] 
> > All of this said, there are other small exchanges that are said to
> > be deploying route servers, but it sounds like these are small regionals.
> 
> I would not agree to this! There is this european internet exchange association (euro-ix) where
> europe's leading ISPs connect to permit the exchange of network information. I am aware of most of
> them using route servers (though not the ones like defined in 1863).

Route collectors or route servers used for other debugging purposes 
are an entirely different thing from route servers used to replace 
iBGP mesh, right?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02466 for <[e-mail]>; Tue, 4 May 2004 11:05:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1Ox-0004hU-Bp; Tue, 04 May 2004 11:00:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1Im-0002RC-AX for [e-mail]; Tue, 04 May 2004 10:53:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06364 for <[e-mail]>; Tue, 4 May 2004 10:53:40 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL1Ij-0000Iw-OK for [e-mail]; Tue, 04 May 2004 10:53:41 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1Ho-0000FS-00 for [e-mail]; Tue, 04 May 2004 10:52:45 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BL1HU-0000B3-00 for [e-mail]; Tue, 04 May 2004 10:52:25 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B19892D4869; Tue,  4 May 2004 10:51:54 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 55586-01-60; Tue,  4 May 2004 10:51:43 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 589082D481F; Tue,  4 May 2004 10:51:43 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i44Epht04774; Tue, 4 May 2004 10:51:43 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Tulip Rasputin <[e-mail]>
Cc: [e-mail]
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, May 04, 2004 at 07:48:49AM -0400
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 10:51:43 -0400

On Tue, May 04, 2004 at 07:48:49AM -0400, Tulip Rasputin wrote:
> I would not agree to this! There is this european internet exchange association (euro-ix) where
> europe's leading ISPs connect to permit the exchange of network information. I am aware of most of
> them using route servers (though not the ones like defined in 1863).

I was unable to find any reference to this on euro-ix.net.
Are they actually using route servers for routing proxy (views) or
are they simply providing a route collector/looking glass?

I would suspect that it is the latter.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA29846 for <[e-mail]>; Tue, 4 May 2004 10:38:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0yk-00054X-9x; Tue, 04 May 2004 10:33:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKyRY-0004wA-IY for [e-mail]; Tue, 04 May 2004 07:50:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25709 for <[e-mail]>; Tue, 4 May 2004 07:50:35 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKyRX-0003fD-M8 for [e-mail]; Tue, 04 May 2004 07:50:35 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKyQb-0003TB-00 for [e-mail]; Tue, 04 May 2004 07:49:38 -0400
Received: from web60704.mail.yahoo.com ([216.109.117.227]) by ietf-mx with smtp (Exim 4.12) id 1BKyQK-0003GN-00 for [e-mail]; Tue, 04 May 2004 07:49:20 -0400
Message-ID: <[e-mail]>
Received: from [202.144.106.186] by web60704.mail.yahoo.com via HTTP; Tue, 04 May 2004 07:48:49 EDT
From: Tulip Rasputin <[e-mail]>
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 4 May 2004 07:48:49 -0400 (EDT)

Jeff,

[..] 
> All of this said, there are other small exchanges that are said to
> be deploying route servers, but it sounds like these are small regionals.

I would not agree to this! There is this european internet exchange association (euro-ix) where
europe's leading ISPs connect to permit the exchange of network information. I am aware of most of
them using route servers (though not the ones like defined in 1863).

> > The 
> > fact that they did not get a wide vendor support is bug not a feature. 
> 
> Please note that RFC 1863 doesn't so much define a route server as
> it does a route-reflector style mechanism for route servers.  This is
> the bit that didn't get wide deployment.

Am sure IXPs would love to have better ways to implement route servers. If there are any IXPs
here, they could probably second me!

> IMO, 1863 is a bit more complicated than what we would want these
> days given modern route reflection techniques.  If a need exists to
> allow multiple views to be passed around in BGP there are better ways
> to go about it.

Like how?

Rasputin.


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA29776 for <[e-mail]>; Tue, 4 May 2004 10:37:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0yj-00054O-Nj; Tue, 04 May 2004 10:33:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKkDL-0002dH-6D for [e-mail]; Mon, 03 May 2004 16:38:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28841 for <[e-mail]>; Mon, 3 May 2004 16:38:56 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKkDJ-00046D-8a for [e-mail]; Mon, 03 May 2004 16:38:57 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKkCC-0003nq-00 for [e-mail]; Mon, 03 May 2004 16:37:49 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BKkB7-0003TC-00 for [e-mail]; Mon, 03 May 2004 16:36:42 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 03 May 2004 13:38:07 -0700
X-BrightmailFiltered: true
Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i43Ka9pI024918; Mon, 3 May 2004 16:36:09 -0400 (EDT)
Received: from localhost (rtp-vpn3-153.cisco.com [10.82.216.153]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA25680; Mon, 3 May 2004 16:36:09 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: Enrico Salazar <[e-mail]>
cc: Cheng-Yin Lee <[e-mail]>, Alex Zinin <[e-mail]>, [e-mail]
Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 16:36:10 -0400 (Eastern Daylight Time)

> Being able to "reconstruct large portions of overall topology" does *not*
> automatically implies being able to "reconstruct the path to each and
> every destination represented by a single prefix within an advertisement
> from the AS_PATH in that advertisement". E.g., from examining AS_PATH fo
> type AS_SEQUENCE one could infer partial information about the inter-AS
> topology.

Okay, if what many people read as the implication of this statement isn't
true, and it's not critical/important to the general operation of BGP, then
why are we leaving it in the draft?

:-)

Russ


__________________________________
[e-mail] CCIE <>< Grace Alone



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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA29261 for <[e-mail]>; Tue, 4 May 2004 10:31:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0ry-0003LU-GQ; Tue, 04 May 2004 10:26:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0pf-0002pM-1I for [e-mail]; Tue, 04 May 2004 10:23:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04050 for <[e-mail]>; Tue, 4 May 2004 10:23:35 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0pc-0005Sw-QB for [e-mail]; Tue, 04 May 2004 10:23:36 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0og-0005P7-00 for [e-mail]; Tue, 04 May 2004 10:22:38 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BL0oE-0005LQ-00 for [e-mail]; Tue, 04 May 2004 10:22:10 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i44ELel06225 for <[e-mail]>; Tue, 4 May 2004 07:21:40 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i44ELZJ76556 for <[e-mail]>; Tue, 4 May 2004 07:21:35 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] draft-scudder-bgp-multisession-00.txt as an IDR WG document 
In-Reply-To: Your message of "Tue, 20 Apr 2004 07:36:41 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 04 May 2004 07:21:35 -0700

Folks,

> Folks,
> 
> Please comment on the attached. The deadline for comments is
> May 3.

There is a consensus to accept draft-scudder-bgp-multisession-00.txt
as an IDR WG document. I'd like to ask authors of that draft
to re-issue it as draft-ietf-idr-bgp-multisession-00.txt

Yakov.
  
> Yakov.
> ------- Forwarded Message
> 
> Date:    Mon, 19 Apr 2004 15:42:25 -0400
> From:    "John G. Scudder" <[e-mail]>
> To:      [e-mail]
> Subject: [Idr] Multisession as WG doc
> 
> Hi Folks,
>   
> I'd like to suggest that Multisession BGP 
> (draft-scudder-bgp-multisession-00.txt) be considered as an IDR 
> working group document.
> 
> Thanks,
> 
> - --John
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
> 
> ------- End of Forwarded Message
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA03736 for <[e-mail]>; Mon, 3 May 2004 23:46:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqok-0006Le-6L; Mon, 03 May 2004 23:42:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqnA-000664-De for [e-mail]; Mon, 03 May 2004 23:40:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21026 for <[e-mail]>; Mon, 3 May 2004 23:40:21 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKqn8-0000YW-BK for [e-mail]; Mon, 03 May 2004 23:40:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqmK-0000Op-00 for [e-mail]; Mon, 03 May 2004 23:39:33 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BKqlK-000037-00 for [e-mail]; Mon, 03 May 2004 23:38:30 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 99E0D2D4875; Mon,  3 May 2004 23:37:56 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43069-01-4; Mon,  3 May 2004 23:37:45 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5A0DE2D483B; Mon,  3 May 2004 23:37:45 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i443bjA03134; Mon, 3 May 2004 23:37:45 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Robert Raszuk <[e-mail]>
Cc: [e-mail]
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, May 03, 2004 at 02:48:34PM -0700
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 23:37:45 -0400

Robert,

1. I don't presume to even *think* about speaking for Merit.
2. That said, I was one of the last of the operators of the RSng project. :-)

On Mon, May 03, 2004 at 02:48:34PM -0700, Robert Raszuk wrote:
> I think Route Servers are widely used in Internet Exchange points.

Towards the end of the RSng project, the route servers were redeployed
as a mechanism by which to concentrate the collection of routing 
statistics for various projects.  The RIS project that RIPE is currently
doing serves many of the same purposes and there are others.

I will honestly say that by the time that I had left RSng that there
were maybe one or two total peers that were using RSD via RSng for
purposes of receiving routing data for forwarding purposes.

All of this said, there are other small exchanges that are said to
be deploying route servers, but it sounds like these are small regionals.
This observation is strictly based on a few random peering BOFs at
past NANOGs, the most recent one that I remember being the last one
in Phoenix.

> The 
> fact that they did not get a wide vendor support is bug not a feature. 

Please note that RFC 1863 doesn't so much define a route server as
it does a route-reflector style mechanism for route servers.  This is
the bit that didn't get wide deployment.

> There are very new evolving applications (example CSC in 2547) which can 
> not scale without vpnv4 multi context route servers. So if anything 
> there is a new work required to extend/update 1863 rather then move it 
> to historic status.

IMO, 1863 is a bit more complicated than what we would want these
days given modern route reflection techniques.  If a need exists to
allow multiple views to be passed around in BGP there are better ways
to go about it.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA07079 for <[e-mail]>; Mon, 3 May 2004 19:12:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmXc-0001gF-F1; Mon, 03 May 2004 19:08:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmPm-0008AT-Sa for [e-mail]; Mon, 03 May 2004 18:59:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10164 for <[e-mail]>; Mon, 3 May 2004 18:59:53 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKmPj-00023U-JE for [e-mail]; Mon, 03 May 2004 18:59:55 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKmOl-0001uC-00 for [e-mail]; Mon, 03 May 2004 18:58:55 -0400
Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1BKmNl-0001dQ-00 for [e-mail]; Mon, 03 May 2004 18:57:54 -0400
Received: from [192.168.0.2] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (sccrmhc12) with ESMTP id <2004050322571801200nhggce> (Authid: hcb8); Mon, 3 May 2004 22:57:19 +0000
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05100302bcbc7d372668@[192.168.0.2]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: [e-mail]
From: "Howard C. Berkowitz" <[e-mail]>
Subject: Re: [Idr] rfc1863 to historic
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 18:57:17 -0400

At 1:12 PM -0700 5/3/04, Yakov Rekhter wrote:
>Folks,
>
>Please comment on the attached request to move rfc1863 to historic.
>The deadline for comments is May 18, 2004.
>
>Yakov.
>------- Forwarded Message
>
>Date:    Mon, 03 May 2004 22:23:25 +0300
>From:    Pekka Savola <[e-mail]>
>To:      [e-mail]
>Subject: RFC1863 to historic? [Re: [Idr] Last Call on 
>draft-ietf-idr-rfc2796bis
>	  -00.txt (fwd)]
>
>Hi,
>
>Should draft-ietf-idr-rfc2796bis-00.txt or some other document also
>make RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh
>routing") historic?
>
>IDRP is at least extict, but are BGP route servers useful for the
>replacement of a full mesh (anymore/at all)?
>
>- ----------------------------
>[..........]
>>   - food for thought: should we kill two birds in one stone, and also
>>     declare RFC1863 ("A BGP/IDRP Route Server alternative to a full
>>     mesh routing") historic?  Is that useful anymore?
>
>This is a good question. May I suggest you'll bring it up to the
>IDR mailing list after we'll finish the WG Last Call on this document
>(as it deserves discussion on its own).

I agree that the specific technique is obsolete, given IDRP is 
obsolete, and was a terrible acronym when anyone tried to pronouce it.

Route servers, however, still appear to be used for research-oriented 
Internet monitoring. It might be appropriate to extract the relevant 
aspects of RS thinking and put them in a new document, to codify 
practices with the various exchange-based servers. This might 
properly be Experimental rather than Standards Track or Informational.

Another possible area of exploration, definitely Experimental, is 
whether a Route Server might serve as a reference implementation for 
at least part of the FORCES control plane entity. In our 
single-router BGP control plane convergence draft, 
draft-ietf-bmwg-conterm-05.txt, provisionally approved as 
Informational by the IESG once we incorporate some useful 
clarifications they suggested, we tried to define language that would 
not preclude either of these applications.

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA01625 for <[e-mail]>; Mon, 3 May 2004 18:18:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlaY-0000GH-4U; Mon, 03 May 2004 18:07:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlL5-0001VW-Df for [e-mail]; Mon, 03 May 2004 17:51:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05653 for <[e-mail]>; Mon, 3 May 2004 17:50:59 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKlL2-0000uU-RD for [e-mail]; Mon, 03 May 2004 17:51:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKlK4-0000nP-00 for [e-mail]; Mon, 03 May 2004 17:50:01 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKlJI-0000YG-00 for [e-mail]; Mon, 03 May 2004 17:49:13 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 May 2004 14:02:51 +0000
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i43LmdW9017026; Mon, 3 May 2004 14:48:39 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-271.cisco.com [10.21.113.15]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASV91424; Mon, 3 May 2004 14:47:50 -0700 (PDT)
Message-ID: <[e-mail]>
From: Robert Raszuk <[e-mail]>
Reply-To: [e-mail]
Organization: Signature: http://www.employees.org/~raszuk/sig/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeffrey Haas <[e-mail]>
CC: Pekka Savola <[e-mail]>, [e-mail]
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,CASHCASHCASH autolearn=no  version=2.60
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 03 May 2004 14:48:34 -0700

IMHO, no.

I think Route Servers are widely used in Internet Exchange points. The 
fact that they did not get a wide vendor support is bug not a feature. 
Note that some vendors can do RS functionality today, but few use a $$$ 
box as a replacement for free soft running on linux which can do just 
fine the same thing :).

There are very new evolving applications (example CSC in 2547) which can 
not scale without vpnv4 multi context route servers. So if anything 
there is a new work required to extend/update 1863 rather then move it 
to historic status.

I am sure folks from Merit, RSNG or other RS creators can provide more 
comments here.

Rgs,
R.


 > Jeffrey Haas wrote:
 >
> On Mon, May 03, 2004 at 10:23:25PM +0300, Pekka Savola wrote:
> 
>>Should draft-ietf-idr-rfc2796bis-00.txt or some other document also
>>make RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh
>>routing") historic?
> 
> 
> IMO, yes.
> 
> 
>>IDRP is at least extict, but are BGP route servers useful for the
>>replacement of a full mesh (anymore/at all)?
> 
> 
> Route servers are still occasionally used by people for various
> purposes, specifically for certain NAPs, but are largely a dead issue.
> As best I know, RFC1863 does not have support by any current vendors
> and never received wide deployment even when route servers were in vogue.
> 


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA27072 for <[e-mail]>; Mon, 3 May 2004 17:33:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKke1-00039f-Lr; Mon, 03 May 2004 17:06:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjxr-000426-Ab for [e-mail]; Mon, 03 May 2004 16:22:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27242 for <[e-mail]>; Mon, 3 May 2004 16:22:56 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKjxp-00018q-EQ for [e-mail]; Mon, 03 May 2004 16:22:57 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKjwx-00012S-00 for [e-mail]; Mon, 03 May 2004 16:22:04 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BKjwc-0000vP-00 for [e-mail]; Mon, 03 May 2004 16:21:42 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 941E92D481E; Mon,  3 May 2004 16:21:12 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31702-01-63; Mon,  3 May 2004 16:21:01 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4C9412D4873; Mon,  3 May 2004 16:21:01 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i43KL1A02396; Mon, 3 May 2004 16:21:01 -0400 (EDT)
From: Jeffrey Haas <[e-mail]>
To: Pekka Savola <[e-mail]>
Cc: [e-mail]
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, May 03, 2004 at 10:23:25PM +0300
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 16:21:01 -0400

On Mon, May 03, 2004 at 10:23:25PM +0300, Pekka Savola wrote:
> Should draft-ietf-idr-rfc2796bis-00.txt or some other document also
> make RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh
> routing") historic?

IMO, yes.

> IDRP is at least extict, but are BGP route servers useful for the
> replacement of a full mesh (anymore/at all)?

Route servers are still occasionally used by people for various
purposes, specifically for certain NAPs, but are largely a dead issue.
As best I know, RFC1863 does not have support by any current vendors
and never received wide deployment even when route servers were in vogue.

-- 
Jeff Haas 
NextHop Technologies

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26931 for <[e-mail]>; Mon, 3 May 2004 17:32:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKkdi-0002zi-Fp; Mon, 03 May 2004 17:06:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjpz-000234-VZ for [e-mail]; Mon, 03 May 2004 16:14:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26622 for <[e-mail]>; Mon, 3 May 2004 16:14:49 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKjpy-0007mZ-8q for [e-mail]; Mon, 03 May 2004 16:14:50 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKjp1-0007b5-00 for [e-mail]; Mon, 03 May 2004 16:13:51 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BKjo1-0007Lc-00 for [e-mail]; Mon, 03 May 2004 16:12:49 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i43KCJBm050336 for <[e-mail]>; Mon, 3 May 2004 13:12:20 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i43KCJJ67347 for <[e-mail]>; Mon, 3 May 2004 13:12:19 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] rfc1863 to historic
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 03 May 2004 13:12:19 -0700

Folks,

Please comment on the attached request to move rfc1863 to historic.
The deadline for comments is May 18, 2004.

Yakov.
------- Forwarded Message

Date:    Mon, 03 May 2004 22:23:25 +0300
From:    Pekka Savola <[e-mail]>
To:      [e-mail]
Subject: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis
	  -00.txt (fwd)]

Hi,

Should draft-ietf-idr-rfc2796bis-00.txt or some other document also
make RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh
routing") historic?

IDRP is at least extict, but are BGP route servers useful for the
replacement of a full mesh (anymore/at all)?

- ----------------------------
[..........]
>  - food for thought: should we kill two birds in one stone, and also 
>    declare RFC1863 ("A BGP/IDRP Route Server alternative to a full 
>    mesh routing") historic?  Is that useful anymore?

This is a good question. May I suggest you'll bring it up to the
IDR mailing list after we'll finish the WG Last Call on this document
(as it deserves discussion on its own).


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

------- End of Forwarded Message


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26848 for <[e-mail]>; Mon, 3 May 2004 17:31:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKkcf-0002RO-8D; Mon, 03 May 2004 17:05:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjm8-0000sg-P6 for [e-mail]; Mon, 03 May 2004 16:10:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26403 for <[e-mail]>; Mon, 3 May 2004 16:10:49 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKjm7-0007BG-3U for [e-mail]; Mon, 03 May 2004 16:10:51 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKjlB-00075E-00 for [e-mail]; Mon, 03 May 2004 16:09:54 -0400
Received: from web90001.mail.scd.yahoo.com ([66.218.94.59]) by ietf-mx with smtp (Exim 4.12) id 1BKjkk-0006yT-00 for [e-mail]; Mon, 03 May 2004 16:09:26 -0400
Message-ID: <[e-mail]>
Received: from [207.17.136.150] by web90001.mail.scd.yahoo.com via HTTP; Mon, 03 May 2004 13:08:56 PDT
From: Enrico Salazar <[e-mail]>
Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt
To: Russ White <[e-mail]>, Cheng-Yin Lee <[e-mail]>
Cc: Alex Zinin <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1908809588-1083614936=:59566"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_YAHOO_RCVD, FROM_ENDS_IN_NUMS,HTML_MESSAGE autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 13:08:56 -0700 (PDT)

--0-1908809588-1083614936=:59566
Content-Type: text/plain; charset=us-ascii

Russ,
 
Being able to "reconstruct large portions of overall topology" does *not* automatically implies being able to "reconstruct the path to each and every destination represented by a single prefix within an advertisement from the AS_PATH in that advertisement". E.g., from examining AS_PATH fo type AS_SEQUENCE one could infer partial information about the inter-AS topology.
 
Enrico

Russ White <[e-mail]> wrote:


> >> BGP uses an algorithm that is neither a pure distance vector
> >> algorithm or a pure link state algorithm. It is instead a modified
> >> distance vector algorithm referred to as a "Path Vector" algorithm
> >> that uses path information to avoid traditional distance vector
> >> problems. Each route within BGP pairs destination with path
> >> information to that destination. Path information (also known as
> >> AS_PATH information) is stored within the AS_PATH attribute in BGP.
> >> This allows BGP to reconstruct large portions of overall topology
> >> whenever required.

> >I've always been uncomfortable with documents saying that BGP
> >reconstructs the overall topology. It doesn't really do this like the
> >link-state protocols do, for example.

> Is this sentence "This allows BGP to reconstruct large portions of
> overall topology ...." talking about using AS_PATH as topology
> information or reconstructing routes/paths?

It's saying you can use the information in the AS_PATH to reconstuct large
portions of the internetwork's overall topology. I've disagreed with this
statement for a while. In fact, I would say you can't even really
reconstruct the path to each and every destination represented by a single
prefix within an advertisement from the AS_PATH in that advertisement,
necessarily.

:-)

Russ

		
---------------------------------
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs 
--0-1908809588-1083614936=:59566
Content-Type: text/html; charset=us-ascii

<DIV>Russ,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Being able to "reconstruct large portions of overall topology" does *not* automatically implies being able to "reconstruct the path to each and every destination represented by a single prefix within an advertisement from the AS_PATH in that advertisement". E.g., from examining AS_PATH fo type AS_SEQUENCE one could infer partial information about the inter-AS topology.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Enrico<BR><BR><B><I>Russ White &lt;[e-mail]&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P><BR>&gt; &gt;&gt; BGP uses an algorithm that is neither a pure distance vector<BR>&gt; &gt;&gt; algorithm or a pure link state algorithm. It is instead a modified<BR>&gt; &gt;&gt; distance vector algorithm referred to as a "Path Vector" algorithm<BR>&gt; &gt;&gt; that uses path information to avoid traditional distance vector<BR>&gt; &gt;&gt; problems. Each route within BGP pairs destination with path<BR>&gt; &gt;&gt; information to that destination. Path information (also known as<BR>&gt; &gt;&gt; AS_PATH information) is stored within the AS_PATH attribute in BGP.<BR>&gt; &gt;&gt; This allows BGP to reconstruct large portions of overall topology<BR>&gt; &gt;&gt; whenever required.<BR><BR>&gt; &gt;I've always been uncomfortable with documents saying that BGP<BR>&gt; &gt;reconstructs the overall topology. It doesn't really do this like the<BR>&gt; &gt;link-state protocols do, for example.<BR><BR>&gt; Is this sentence "This allows BGP to reconstruct large portions of<BR>&gt!
 ; overall
 topology ...." talking about using AS_PATH as topology<BR>&gt; information or reconstructing routes/paths?<BR><BR>It's saying you can use the information in the AS_PATH to reconstuct large<BR>portions of the internetwork's overall topology. I've disagreed with this<BR>statement for a while. In fact, I would say you can't even really<BR>reconstruct the path to each and every destination represented by a single<BR>prefix within an advertisement from the AS_PATH in that advertisement,<BR>necessarily.<BR><BR>:-)<BR><BR>Russ</P></BLOCKQUOTE><p>
		<hr size=1><font face=arial size=-1>Do you Yahoo!?<br><a href="http://pa.yahoo.com/*http://us.rd.yahoo.com/hotjobs/hotjobs_mail_signature_footer_textlink/evt=23983/*http://hotjobs.sweepstakes.yahoo.com/careermakeover">Win a $20,000 Career Makeover at Yahoo! HotJobs </a>
--0-1908809588-1083614936=:59566--

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA16122 for <[e-mail]>; Mon, 3 May 2004 15:42:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjCX-0006XP-T0; Mon, 03 May 2004 15:34:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKj4X-0004kq-AL for [e-mail]; Mon, 03 May 2004 15:25:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23752 for <[e-mail]>; Mon, 3 May 2004 15:25:47 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKj4W-00026z-1p for [e-mail]; Mon, 03 May 2004 15:25:48 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKj3Y-00020Y-00 for [e-mail]; Mon, 03 May 2004 15:24:49 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BKj2h-0001p4-00 for [e-mail]; Mon, 03 May 2004 15:23:55 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i43JNPl20196 for <[e-mail]>; Mon, 3 May 2004 22:23:25 +0300
From: Pekka Savola <[e-mail]>
To: [e-mail]
Subject: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 22:23:25 +0300 (EEST)

Hi,

Should draft-ietf-idr-rfc2796bis-00.txt or some other document also
make RFC1863 ("A BGP/IDRP Route Server alternative to a full mesh
routing") historic?

IDRP is at least extict, but are BGP route servers useful for the
replacement of a full mesh (anymore/at all)?

----------------------------
[..........]
>  - food for thought: should we kill two birds in one stone, and also 
>    declare RFC1863 ("A BGP/IDRP Route Server alternative to a full 
>    mesh routing") historic?  Is that useful anymore?

This is a good question. May I suggest you'll bring it up to the
IDR mailing list after we'll finish the WG Last Call on this document
(as it deserves discussion on its own).


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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13469 for <[e-mail]>; Mon, 3 May 2004 15:14:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKijb-0006Yn-AR; Mon, 03 May 2004 15:04:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiUp-0006bY-9F for [e-mail]; Mon, 03 May 2004 14:48:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19992 for <[e-mail]>; Mon, 3 May 2004 14:48:51 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKiUm-0005IF-DV for [e-mail]; Mon, 03 May 2004 14:48:52 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiTw-0005Bm-00 for [e-mail]; Mon, 03 May 2004 14:48:01 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BKiT6-00055D-00 for [e-mail]; Mon, 03 May 2004 14:47:08 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i43IkLaL018289; Mon, 3 May 2004 14:46:21 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pekka Savola <[e-mail]>
cc: Curtis Villamizar <[e-mail]>, Pedro Roque Marques <[e-mail]>, Yakov Rekhter <[e-mail]>, Alex Zinin <[e-mail]>, [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
In-reply-to: Your message of "Mon, 03 May 2004 21:29:49 +0300." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 03 May 2004 14:46:21 -0400

In message <[e-mail]>, Pekka Savola 
writes:
> On Mon, 3 May 2004, Curtis Villamizar wrote:
> [...]
> > BGP/IGP interaction does not belong in the base BGP specification.
> > We've had consensus on that for many years and when it came up again
> > during this iteration within the WG it seemed to me we still had
> > consensus on that.
> 
> Note that I'm not calling for BGP/IGP interactions as described e.g., 
> in RFC1745.  That seems to mostly describe how to redistribute the 
> information between different protocols.
> 
> However, I'm interested in ensuring that BGP remains usable in the
> operations.  As it is, the current "active route condition" fails when
> you want to advertise the loopbacks and point-to-point (also) in BGP,
> not just the IGP.  That's a major scenario which has to be addressed,
> IMHO.
> 
> (And this has been already been addressed in all the implementations
> I've used, so this is really not just theory -- it's implemented and
> out there.)
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



You should look in the work group mailing list archives.  This too was
discussed at great length and quite recently and we acheived consensus
that it was a topic for a separate internet-draft.  No one volunteered
to write that separate draft (so far) but that does not affect the BGP
spec.

Curtis

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA11578 for <[e-mail]>; Mon, 3 May 2004 14:54:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiMD-0004f7-Uo; Mon, 03 May 2004 14:40:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiEX-00024c-Ow for [e-mail]; Mon, 03 May 2004 14:32:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18701 for <[e-mail]>; Mon, 3 May 2004 14:32:02 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKiEV-0003Ee-5X for [e-mail]; Mon, 03 May 2004 14:32:03 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiDM-00035V-00 for [e-mail]; Mon, 03 May 2004 14:30:53 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BKiCy-0002zP-00 for [e-mail]; Mon, 03 May 2004 14:30:28 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i43ITnl19297; Mon, 3 May 2004 21:29:49 +0300
From: Pekka Savola <[e-mail]>
To: Curtis Villamizar <[e-mail]>
cc: Pedro Roque Marques <[e-mail]>, Yakov Rekhter <[e-mail]>, Alex Zinin <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 21:29:49 +0300 (EEST)

On Mon, 3 May 2004, Curtis Villamizar wrote:
[...]
> BGP/IGP interaction does not belong in the base BGP specification.
> We've had consensus on that for many years and when it came up again
> during this iteration within the WG it seemed to me we still had
> consensus on that.

Note that I'm not calling for BGP/IGP interactions as described e.g., 
in RFC1745.  That seems to mostly describe how to redistribute the 
information between different protocols.

However, I'm interested in ensuring that BGP remains usable in the
operations.  As it is, the current "active route condition" fails when
you want to advertise the loopbacks and point-to-point (also) in BGP,
not just the IGP.  That's a major scenario which has to be addressed,
IMHO.

(And this has been already been addressed in all the implementations
I've used, so this is really not just theory -- it's implemented and
out there.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings




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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA10257 for <[e-mail]>; Mon, 3 May 2004 14:41:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiJJ-0003Si-Ls; Mon, 03 May 2004 14:37:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKi2h-0007Z6-Is for [e-mail]; Mon, 03 May 2004 14:19:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18044 for <[e-mail]>; Mon, 3 May 2004 14:19:48 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKi2f-0001mT-06 for [e-mail]; Mon, 03 May 2004 14:19:49 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKi1l-0001g5-00 for [e-mail]; Mon, 03 May 2004 14:18:53 -0400
Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1BKi0v-0001U0-00 for [e-mail]; Mon, 03 May 2004 14:18:01 -0400
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i43IHVG4024658; Mon, 3 May 2004 11:17:31 -0700
Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i43IHVgZ024657; Mon, 3 May 2004 11:17:31 -0700
X-Authentication-Warning: m106.maoz.com: dmm set sender to [e-mail] using -f
From: David Meyer <[e-mail]>
To: Susan Hares <[e-mail]>
Cc: Pekka Savola <[e-mail]>, Yakov Rekhter <[e-mail]>, Alex Zinin <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I just had to let it go" -- John Lennon
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 11:17:31 -0700

	All,

On Mon, May 03, 2004 at 01:48:31PM -0400, Susan Hares wrote:
>> Pekka:
>> 
>> 
>> There was a specification (now historical)
>> that talked about knobs between OSPF and 
>> BGP (RFC 1745).  We put the knobs for IGP/EGPs
>> into this document. 
>> 
>> So perhaps you want to review this document 
>> and look at the what it covered.  If you feel
>> that document is useful, let me know.
>> I was a co-author on this document originally, but
>> Dave Meyer felt it should go to historical.
>> Please chat with him about why he thought
>> it should go to historical.

	The reasoning is in RFC 3167 (Request to Move RFC 1745 to
	Historic Status).   

	Let me know if there are things not covered there that
	need clarifcation.

	Dave

>> If you feel this document should be updated,
>> please let me know.  I'm glad to engage in
>> a conversation about whether the OSPF/ISIS and
>> BGP interaction should be discussed.
>> 
>> Sue
>> 
>> -----Original Message-----
>> From: Pekka Savola [mailto:[e-mail]]
>> Sent: Friday, April 30, 2004 1:19 PM
>> To: Yakov Rekhter
>> Cc: Alex Zinin; [e-mail]; [e-mail]
>> Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)'
>> to Draft Standard 
>> 
>> 
>> On Fri, 30 Apr 2004, Yakov Rekhter wrote:
>> > > I think this is operationally a rather common (or even very common)  
>> > > scenario, and it would seem very disadvantageous not to tackle it in
>> > > this specification.  Further, there's major deployment of it (maybe
>> > > even multi-vendor -- probably) so there is considerable proof that it
>> > > works.
>> > > 
>> > > It should be the default behaviour of BGP as that's which makes the
>> > > most sense, operationally.  "BGP route is ... used by forwarding" does
>> > > not sufficiently cover the fact that people do use IGPs and there's
>> > > often overlap with IGP and BGP :).
>> > 
>> > People do use IGPs, and there is interaction between IGPs and BGP.
>> > 
>> > It is just that the based BGP protocol spec is *not* the place to 
>> > document the interaction between BGP and IGPs.
>> 
>> I have to disagree here.  BGP is useless without IGP.  Failing to
>> consider that would mean a specifition disconnected from the reality.
>> 
>> -- 
>> Pekka Savola                 "You each name yourselves king, yet the
>> Netcore Oy                    kingdom bleeds."
>> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>> 
>> 
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr
>> 
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA09173 for <[e-mail]>; Mon, 3 May 2004 14:30:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhy4-0006Rb-JS; Mon, 03 May 2004 14:15:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhkE-00030Y-KA for [e-mail]; Mon, 03 May 2004 14:00:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16955 for <[e-mail]>; Mon, 3 May 2004 14:00:43 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhkC-0007SM-5q for [e-mail]; Mon, 03 May 2004 14:00:44 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhjL-0007Ma-00 for [e-mail]; Mon, 03 May 2004 13:59:51 -0400
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1BKhiP-0007GN-00 for [e-mail]; Mon, 03 May 2004 13:58:53 -0400
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i43Hw8aL018014; Mon, 3 May 2004 13:58:08 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pekka Savola <[e-mail]>
cc: Pedro Roque Marques <[e-mail]>, Yakov Rekhter <[e-mail]>, Alex Zinin <[e-mail]>, [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
In-reply-to: Your message of "Mon, 03 May 2004 20:29:34 +0300." <[e-mail]> 
From: Curtis Villamizar <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 03 May 2004 13:58:08 -0400

In message <[e-mail]>, Pekka Savola 
writes:
> On Fri, 30 Apr 2004, Pedro Roque Marques wrote:
> > One simply cannot put all the bits of information required to make bgp
> > "useful" in the base specification and still have a readable document.
> 
> This is an operationally critical piece.  Moreover, I think all the
> implementations out there (that I'm aware of -- I've probably missed
> some!) already support this behaviour (whether it's default or not is
> another question), which again is a thing worth considering here.
>  
> > moreever the iteraction procedures that you seem to want to document
> > are not something the wg has achieved consensus on. there are still
> > different opinions on this topic and different deployed
> > behaviours. Thus including this topic in the base protocol spec seems
> > to me to be contrary to the original goals of revising the
> > specification.
> 
> Would this call for achieving that consensus, if it does not exist?
>  
> > I would also like to point out that several outher people have
> > expressed the opinion that this topic should be left out of the base
> > spec. In fact i would claim that there is consensus on that ammong the
> > wg.
> 
> It seems to me that only you have stated opinions against that.  Vijay 
> Gill appeared to support my proposal (in more general terms), and 
> Gargi Nalawade didn't say much one way or the other, but volunteered 
> for proposing the text on the "new wording".
> 
> Unless I'm missing someone's mails, I don't see think your statement
> is accurate.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



BGP/IGP interaction does not belong in the base BGP specification.
We've had consensus on that for many years and when it came up again
during this iteration within the WG it seemed to me we still had
consensus on that.

Curtis

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA07778 for <[e-mail]>; Mon, 3 May 2004 14:13:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhiX-0002ln-TC; Mon, 03 May 2004 13:59:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhai-0000qr-HU for [e-mail]; Mon, 03 May 2004 13:50:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16444 for <[e-mail]>; Mon, 3 May 2004 13:50:53 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhag-0006QB-9K for [e-mail]; Mon, 03 May 2004 13:50:54 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhZm-0006KY-00 for [e-mail]; Mon, 03 May 2004 13:49:59 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BKhZ5-0006Cl-00 for [e-mail]; Mon, 03 May 2004 13:49:15 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B2A972D487A for <[e-mail]>; Mon,  3 May 2004 13:48:45 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28847-01 for <[e-mail]>; Mon,  3 May 2004 13:48:31 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 802DE2D4838 for <[e-mail]>; Mon,  3 May 2004 13:48:31 -0400 (EDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
Message-ID: <[e-mail]>
Thread-Topic: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
Thread-Index: AcQu2Qxfu7yI63ItRdW2pLwbFJhfQgAOZxvg
From: "Susan Hares" <[e-mail]>
To: "Pekka Savola" <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Cc: "Alex Zinin" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 13:48:31 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA07778

Pekka:


There was a specification (now historical)
that talked about knobs between OSPF and 
BGP (RFC 1745).  We put the knobs for IGP/EGPs
into this document. 

So perhaps you want to review this document 
and look at the what it covered.  If you feel
that document is useful, let me know.
I was a co-author on this document originally, but
Dave Meyer felt it should go to historical.
Please chat with him about why he thought
it should go to historical.

If you feel this document should be updated,
please let me know.  I'm glad to engage in
a conversation about whether the OSPF/ISIS and
BGP interaction should be discussed.

Sue

-----Original Message-----
From: Pekka Savola [mailto:[e-mail]]
Sent: Friday, April 30, 2004 1:19 PM
To: Yakov Rekhter
Cc: Alex Zinin; [e-mail]; [e-mail]
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)'
to Draft Standard 


On Fri, 30 Apr 2004, Yakov Rekhter wrote:
> > I think this is operationally a rather common (or even very common)  
> > scenario, and it would seem very disadvantageous not to tackle it in
> > this specification.  Further, there's major deployment of it (maybe
> > even multi-vendor -- probably) so there is considerable proof that it
> > works.
> > 
> > It should be the default behaviour of BGP as that's which makes the
> > most sense, operationally.  "BGP route is ... used by forwarding" does
> > not sufficiently cover the fact that people do use IGPs and there's
> > often overlap with IGP and BGP :).
> 
> People do use IGPs, and there is interaction between IGPs and BGP.
> 
> It is just that the based BGP protocol spec is *not* the place to 
> document the interaction between BGP and IGPs.

I have to disagree here.  BGP is useless without IGP.  Failing to
consider that would mean a specifition disconnected from the reality.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA05542 for <[e-mail]>; Mon, 3 May 2004 13:51:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhNF-0005tp-RY; Mon, 03 May 2004 13:37:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhIA-0004T2-Dc for [e-mail]; Mon, 03 May 2004 13:31:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15257 for <[e-mail]>; Mon, 3 May 2004 13:31:43 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhI8-0004JZ-A7 for [e-mail]; Mon, 03 May 2004 13:31:44 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhHD-0004Dv-00 for [e-mail]; Mon, 03 May 2004 13:30:48 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BKhGb-00044F-00 for [e-mail]; Mon, 03 May 2004 13:30:09 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i43HTYa18102; Mon, 3 May 2004 20:29:34 +0300
From: Pekka Savola <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
cc: Yakov Rekhter <[e-mail]>, Alex Zinin <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 20:29:34 +0300 (EEST)

On Fri, 30 Apr 2004, Pedro Roque Marques wrote:
> One simply cannot put all the bits of information required to make bgp
> "useful" in the base specification and still have a readable document.

This is an operationally critical piece.  Moreover, I think all the
implementations out there (that I'm aware of -- I've probably missed
some!) already support this behaviour (whether it's default or not is
another question), which again is a thing worth considering here.
 
> moreever the iteraction procedures that you seem to want to document
> are not something the wg has achieved consensus on. there are still
> different opinions on this topic and different deployed
> behaviours. Thus including this topic in the base protocol spec seems
> to me to be contrary to the original goals of revising the
> specification.

Would this call for achieving that consensus, if it does not exist?
 
> I would also like to point out that several outher people have
> expressed the opinion that this topic should be left out of the base
> spec. In fact i would claim that there is consensus on that ammong the
> wg.

It seems to me that only you have stated opinions against that.  Vijay 
Gill appeared to support my proposal (in more general terms), and 
Gargi Nalawade didn't say much one way or the other, but volunteered 
for proposing the text on the "new wording".

Unless I'm missing someone's mails, I don't see think your statement
is accurate.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA00190 for <[e-mail]>; Mon, 3 May 2004 12:52:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgYx-0001E7-5n; Mon, 03 May 2004 12:45:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgN3-0006lu-Ri for [e-mail]; Mon, 03 May 2004 12:32:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11458 for <[e-mail]>; Mon, 3 May 2004 12:32:42 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKgN2-0005WJ-AU for [e-mail]; Mon, 03 May 2004 12:32:44 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgM9-0005Sf-00 for [e-mail]; Mon, 03 May 2004 12:31:50 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BKgLf-0005OX-00 for [e-mail]; Mon, 03 May 2004 12:31:19 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 813AA2D48BC for <[e-mail]>; Mon,  3 May 2004 12:30:43 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26868-02-4 for <[e-mail]>; Mon,  3 May 2004 12:30:30 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7651E2D487A for <[e-mail]>; Mon,  3 May 2004 12:30:27 -0400 (EDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4  (BGP-4)' to Draft Standard 
Message-ID: <[e-mail]>
Thread-Topic: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4  (BGP-4)' to Draft Standard 
Thread-Index: AcQu966m5y0Jx6ChRcyk25GiXAPTVQCNAYmQ
From: "Susan Hares" <[e-mail]>
To: "Dinara Suleymanova" <[e-mail]>, "Pekka Savola" <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Cc: "Alex Zinin" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 12:30:27 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id MAA00190

Dinara:

What exactly do you want unsubscribe:

[e-mail]

This ID is turned off.  

Sue

-----Original Message-----
From: Dinara Suleymanova [mailto:[e-mail]]
Sent: Thursday, April 29, 2004 2:01 PM
To: Pekka Savola; Yakov Rekhter
Cc: Alex Zinin; [e-mail]; [e-mail]
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)'
to Draft Standard 


Hello,

Could it be possible to UN-subscribe us/me (not sure what address was added 
on your subscription list)
from your discussion list.

Thanks a lot.

Dinara Suleymanova


At 12:35 PM 4/29/2004, Pekka Savola wrote:
>On Tue, 20 Apr 2004, Yakov Rekhter wrote:
> > > >  2) The definition of active route is bad.  This fails in the
> > > >     situation where you need to export loopbacks/point-to-points to
> > > >     eBGP, but you have them in youro IGP.  The specification does not
> > > >     consider them active (not used for forwarding), and they aren't
> > > >     exported.
> > > >
> > > >     When the next-hop of the IGP route is the same as BGP next-hop,
> > > >     obviously this is no problem.  Gargi Nalawade promised to submit
> > > >     text, but hasn't, and I think Yakov said something about being
> > > >     willing to incorporate that, but obviously hasn't.
> > > >
> > > >     This was discussed at idr thread:
> > >
> > > >       issue 11.2: active route, again
> > >
> > > > Otherwise, I think this was operationally good.
> > >
> > > Sue, Yakov, please check if the ball was dropped re this one.
> >
> > First of all, the consensus of the WG (as documented in
> > draft-ietf-idr-bgp-issues) is to have the following text:
> >
> >    In the context of this document we assume that a BGP speaker
> >    advertises to its peers only those routes that it itself uses (in
> >    this context a BGP speaker is said to "use" a BGP route if it is the
> >    most preferred BGP route and is used in forwarding). All other cases
> >    are outside the scope of this document.
> >
> > While this text does not cover the case described by Pekka, it does
> > not preclude it either - handling the case described by Pekka
> > is just outside the scope of the spec.
> >
> > With this in mind I suggest that the case described by Pekka
> > should be covered in a separate Internet Draft.
>
>I think this is operationally a rather common (or even very common)
>scenario, and it would seem very disadvantageous not to tackle it in
>this specification.  Further, there's major deployment of it (maybe
>even multi-vendor -- probably) so there is considerable proof that it
>works.
>
>It should be the default behaviour of BGP as that's which makes the
>most sense, operationally.  "BGP route is ... used by forwarding" does
>not sufficiently cover the fact that people do use IGPs and there's
>often overlap with IGP and BGP :).
>
>--
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr



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

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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA29507 for <[e-mail]>; Mon, 3 May 2004 12:44:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgNJ-0006mW-JA; Mon, 03 May 2004 12:33:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbcm-00034D-Ur for [e-mail]; Mon, 03 May 2004 07:28:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21593 for <[e-mail]>; Mon, 3 May 2004 07:28:39 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKbcm-0000uj-5v for [e-mail]; Mon, 03 May 2004 07:28:40 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKbZh-0000N1-00 for [e-mail]; Mon, 03 May 2004 07:25:30 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BKbWG-0007Ne-00 for [e-mail]; Mon, 03 May 2004 07:21:56 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 03 May 2004 04:23:13 -0700
X-BrightmailFiltered: true
Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i43BLJYu023237; Mon, 3 May 2004 07:21:19 -0400 (EDT)
Received: from localhost (rtp-vpn3-153.cisco.com [10.82.216.153]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA27608; Mon, 3 May 2004 07:21:19 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: Cheng-Yin Lee <[e-mail]>
cc: Alex Zinin <[e-mail]>, [e-mail]
Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 3 May 2004 07:21:21 -0400 (Eastern Daylight Time)

> >>   BGP uses an algorithm that is neither a pure distance vector
> >>   algorithm or a pure link state algorithm.  It is instead a modified
> >>   distance vector algorithm referred to as a "Path Vector" algorithm
> >>   that uses path information to avoid traditional distance vector
> >>   problems.  Each route within BGP pairs destination with path
> >>   information to that destination.  Path information (also known as
> >>   AS_PATH information) is stored within the AS_PATH attribute in BGP.
> >>   This allows BGP to reconstruct large portions of overall topology
> >>   whenever required.

> >I've always been uncomfortable with documents saying that BGP
> >reconstructs the overall topology. It doesn't really do this like the
> >link-state protocols do, for example.

> Is this sentence "This allows BGP to reconstruct large portions of
> overall topology ...." talking about using AS_PATH as topology
> information or reconstructing routes/paths?

It's saying you can use the information in the AS_PATH to reconstuct large
portions of the internetwork's overall topology. I've disagreed with this
statement for a while. In fact, I would say you can't even really
reconstruct the path to each and every destination represented by a single
prefix within an advertisement from the AS_PATH in that advertisement,
necessarily.

:-)

Russ

__________________________________
[e-mail] CCIE <>< Grace Alone



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


Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA26319 for <[e-mail]>; Sun, 2 May 2004 11:57:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKJI1-0004Ds-ON; Sun, 02 May 2004 11:54:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKJH6-0003vm-N5 for [e-mail]; Sun, 02 May 2004 11:53:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19350 for <[e-mail]>; Sun, 2 May 2004 11:53:02 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKJH5-0006pU-IG for [e-mail]; Sun, 02 May 2004 11:53:03 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKJG5-0006ZV-00 for [e-mail]; Sun, 02 May 2004 11:52:01 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BKJF8-00066H-00 for [e-mail]; Sun, 02 May 2004 11:51:02 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i42FoVl94531 for <[e-mail]>; Sun, 2 May 2004 08:50:31 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i42FoQJ33594 for <[e-mail]>; Sun, 2 May 2004 08:50:26 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
From: Yakov Rekhter <[e-mail]>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Idr] draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Sun, 02 May 2004 08:50:26 -0700

Folks,

We didn't get sufficient consensus to accept 
draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document. 

The authors of draft-chavali-bgp-prefixlimit-01.txt produced
a new version, draft-chavali-bgp-prefixlimit-02.txt, and would
like the IDR WG to accept this *new* version as an IDR WG document.

Please send comments to the list. The deadline for comments is 
May 17, 2004.

Yakov. 

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