From routing-discussion-admin@ietf.org Mon May 3 21:38:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15771 for ; Mon, 3 May 2004 21:38: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 1BKont-0006Mv-De; Mon, 03 May 2004 21: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 1BKomE-0006CZ-GO for routing-discussion@optimus.ietf.org; Mon, 03 May 2004 21:31: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 VAA15568 for ; Mon, 3 May 2004 21:31: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 1BKomB-0005pv-Ol for routing-discussion@ietf.org; Mon, 03 May 2004 21:31:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKolF-0005h9-00 for routing-discussion@ietf.org; Mon, 03 May 2004 21:30:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BKoke-0005Yn-00 for routing-discussion@ietf.org; Mon, 03 May 2004 21:29:40 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKoke-000Ife-Mp for routing-discussion@ietf.org; Tue, 04 May 2004 01:29:40 +0000 Date: Mon, 3 May 2004 18:29:39 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <19150967.20040503182939@psg.com> To: routing-discussion@ietf.org Subject: Updated version posted: draft-kompella-zinin-early-allocation-01.txt 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 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 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 routing-discussion@ietf.org, 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 routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon May 3 21:40:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15856 for ; Mon, 3 May 2004 21:40: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 1BKot6-0007gD-9T for routing-discussion-archive@odin.ietf.org; Mon, 03 May 2004 21:38:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i441cOLH029447 for routing-discussion-archive@odin.ietf.org; Mon, 3 May 2004 21:38:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKont-0006Mv-De; Mon, 03 May 2004 21: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 1BKomE-0006CZ-GO for routing-discussion@optimus.ietf.org; Mon, 03 May 2004 21:31: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 VAA15568 for ; Mon, 3 May 2004 21:31: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 1BKomB-0005pv-Ol for routing-discussion@ietf.org; Mon, 03 May 2004 21:31:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKolF-0005h9-00 for routing-discussion@ietf.org; Mon, 03 May 2004 21:30:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BKoke-0005Yn-00 for routing-discussion@ietf.org; Mon, 03 May 2004 21:29:40 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKoke-000Ife-Mp for routing-discussion@ietf.org; Tue, 04 May 2004 01:29:40 +0000 Date: Mon, 3 May 2004 18:29:39 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <19150967.20040503182939@psg.com> To: routing-discussion@ietf.org Subject: Updated version posted: draft-kompella-zinin-early-allocation-01.txt 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 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 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 routing-discussion@ietf.org, 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 routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu May 13 07:57:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06688 for ; Thu, 13 May 2004 07:57: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 1BOElq-00082u-Eo; Thu, 13 May 2004 07:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOEio-0007Z6-RZ for routing-discussion@optimus.ietf.org; Thu, 13 May 2004 07:49: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 HAA06398 for ; Thu, 13 May 2004 07:49: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 1BOEio-0003o1-4K for routing-discussion@ietf.org; Thu, 13 May 2004 07:49:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOEhm-0003Fg-00 for routing-discussion@ietf.org; Thu, 13 May 2004 07:48:51 -0400 Received: from web40308.mail.yahoo.com ([66.218.78.87]) by ietf-mx with smtp (Exim 4.12) id 1BOEgd-0002Cn-00 for routing-discussion@ietf.org; Thu, 13 May 2004 07:47:39 -0400 Message-ID: <20040513114708.96392.qmail@web40308.mail.yahoo.com> Received: from [203.124.240.10] by web40308.mail.yahoo.com via HTTP; Thu, 13 May 2004 04:47:08 PDT Date: Thu, 13 May 2004 04:47:08 -0700 (PDT) From: Abhishek Mittal Subject: vty session gets hang To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-541749786-1084448828=:94318" 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,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0-541749786-1084448828=:94318 Content-Type: text/plain; charset=us-ascii Hi All, I have one observation other then routing issues.Sorry for discussing it here. Many times i have observed that telnet session thru vty shows user connected for more then the exec-timeout.Although we have given the exec timeout command in line vty. Some log is from route-views.oregon-ix.net (Route-Server) route-views.oregon-ix.net>sh users Line User Host(s) Idle Location 2 vty 0 idle 00:00:06 herprd18.nss.rr.com 3 vty 1 idle 1d18h 203.115.112.148 4 vty 2 idle 07:54:45 nbc1.betaclub.org 5 vty 3 idle 00:00:03 208.35.10.30 7 vty 5 rviews idle 00:01:30 bzq-165-45.dsl.bezeqint.net Interface User Mode Idle Peer Address route-views.oregon-ix.net> In above log, vty 1 is showing idle and no user name is showing for this.I think , this route-server admin must given the exec-timeout command for vty sessions. But still it is showing the session more then 1day 18 hrs old. This problem I have observed in many cisco IOS version.And due to this behavior , we had reboot our one of 3660 router. Can any one tell me , is it a bug or some thing else?Why it happens? Thanks in advance. Regards Abhishek Mittal --------------------------------- Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' --0-541749786-1084448828=:94318 Content-Type: text/html; charset=us-ascii
Hi All,
 
I have one observation other then routing issues.Sorry for discussing it here.
 
Many times i have observed that telnet session thru vty shows user connected for more then the exec-timeout.Although we have given the exec timeout command in line vty.
Some log is from route-views.oregon-ix.net (Route-Server)
route-views.oregon-ix.net>sh users
    Line       User       Host(s)              Idle       Location
   2 vty 0                idle                 00:00:06 herprd18.nss.rr.com
   3 vty 1                idle                    1d18h 203.115.112.148
   4 vty 2                idle               ! ;  07:54:45 nbc1.betaclub.org
   5 vty 3                idle                 00:00:03 208.35.10.30
   7 vty 5     rviews     idle                 00:01:30 bzq-165-45.dsl.bezeqint.net
  Interface      User        Mode                     Idle     Peer Address
route-views.oregon-ix.net>
In above log, vty 1 is showing idle and no user name is showing for this.I think , this route-server admin must given the exec-timeout command for vty sessions. But still it is showing the session more then 1day 18 hrs old.
 
This problem I have observed in many cisco IOS version.And due to this behavior , we had reboot our one of 3660 router.
 
Can any one tell me , is it a bug or some thing else?Why it happens?
 
Thanks in advance.
 
Regards
Abhishek Mittal
 

Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2' --0-541749786-1084448828=:94318-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu May 13 08:01:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06798 for ; Thu, 13 May 2004 08: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 1BOEpa-000093-RC for routing-discussion-archive@odin.ietf.org; Thu, 13 May 2004 07:56:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DBusuR000558 for routing-discussion-archive@odin.ietf.org; Thu, 13 May 2004 07:56:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOElq-00082u-Eo; Thu, 13 May 2004 07:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOEio-0007Z6-RZ for routing-discussion@optimus.ietf.org; Thu, 13 May 2004 07:49: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 HAA06398 for ; Thu, 13 May 2004 07:49: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 1BOEio-0003o1-4K for routing-discussion@ietf.org; Thu, 13 May 2004 07:49:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOEhm-0003Fg-00 for routing-discussion@ietf.org; Thu, 13 May 2004 07:48:51 -0400 Received: from web40308.mail.yahoo.com ([66.218.78.87]) by ietf-mx with smtp (Exim 4.12) id 1BOEgd-0002Cn-00 for routing-discussion@ietf.org; Thu, 13 May 2004 07:47:39 -0400 Message-ID: <20040513114708.96392.qmail@web40308.mail.yahoo.com> Received: from [203.124.240.10] by web40308.mail.yahoo.com via HTTP; Thu, 13 May 2004 04:47:08 PDT Date: Thu, 13 May 2004 04:47:08 -0700 (PDT) From: Abhishek Mittal Subject: vty session gets hang To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-541749786-1084448828=:94318" 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,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0-541749786-1084448828=:94318 Content-Type: text/plain; charset=us-ascii Hi All, I have one observation other then routing issues.Sorry for discussing it here. Many times i have observed that telnet session thru vty shows user connected for more then the exec-timeout.Although we have given the exec timeout command in line vty. Some log is from route-views.oregon-ix.net (Route-Server) route-views.oregon-ix.net>sh users Line User Host(s) Idle Location 2 vty 0 idle 00:00:06 herprd18.nss.rr.com 3 vty 1 idle 1d18h 203.115.112.148 4 vty 2 idle 07:54:45 nbc1.betaclub.org 5 vty 3 idle 00:00:03 208.35.10.30 7 vty 5 rviews idle 00:01:30 bzq-165-45.dsl.bezeqint.net Interface User Mode Idle Peer Address route-views.oregon-ix.net> In above log, vty 1 is showing idle and no user name is showing for this.I think , this route-server admin must given the exec-timeout command for vty sessions. But still it is showing the session more then 1day 18 hrs old. This problem I have observed in many cisco IOS version.And due to this behavior , we had reboot our one of 3660 router. Can any one tell me , is it a bug or some thing else?Why it happens? Thanks in advance. Regards Abhishek Mittal --------------------------------- Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' --0-541749786-1084448828=:94318 Content-Type: text/html; charset=us-ascii
Hi All,
 
I have one observation other then routing issues.Sorry for discussing it here.
 
Many times i have observed that telnet session thru vty shows user connected for more then the exec-timeout.Although we have given the exec timeout command in line vty.
Some log is from route-views.oregon-ix.net (Route-Server)
route-views.oregon-ix.net>sh users
    Line       User       Host(s)              Idle       Location
   2 vty 0                idle                 00:00:06 herprd18.nss.rr.com
   3 vty 1                idle                    1d18h 203.115.112.148
   4 vty 2                idle               ! ;  07:54:45 nbc1.betaclub.org
   5 vty 3                idle                 00:00:03 208.35.10.30
   7 vty 5     rviews     idle                 00:01:30 bzq-165-45.dsl.bezeqint.net
  Interface      User        Mode                     Idle     Peer Address
route-views.oregon-ix.net>
In above log, vty 1 is showing idle and no user name is showing for this.I think , this route-server admin must given the exec-timeout command for vty sessions. But still it is showing the session more then 1day 18 hrs old.
 
This problem I have observed in many cisco IOS version.And due to this behavior , we had reboot our one of 3660 router.
 
Can any one tell me , is it a bug or some thing else?Why it happens?
 
Thanks in advance.
 
Regards
Abhishek Mittal
 

Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2' --0-541749786-1084448828=:94318-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu May 13 14:19:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02065 for ; Thu, 13 May 2004 14:19: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 1BOKKR-0006bY-D5; Thu, 13 May 2004 13:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJpy-0001zH-G9 for routing-discussion@optimus.ietf.org; Thu, 13 May 2004 13:17:38 -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 NAA24772 for ; Thu, 13 May 2004 13:17: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 1BOJpw-0000A9-Hl for routing-discussion@ietf.org; Thu, 13 May 2004 13:17:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOJos-0007NX-00 for routing-discussion@ietf.org; Thu, 13 May 2004 13:16:31 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BOJo9-0006oT-00 for routing-discussion@ietf.org; Thu, 13 May 2004 13:15:45 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOJo9-000Bfn-5t; Thu, 13 May 2004 17:15:45 +0000 Date: Thu, 13 May 2004 10:15:43 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1727441504.20040513101543@psg.com> To: Abhishek Mittal CC: routing-discussion@ietf.org Subject: Re: vty session gets hang In-Reply-To: <20040513114708.96392.qmail@web40308.mail.yahoo.com> References: <20040513114708.96392.qmail@web40308.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 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: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Abhishek, This is _really_ a wrong forum for this question. Please take it to your vendor's technical support, or comp.dcom.sys.cisco or the cisco-nsp mailing list. -- Alex http://www.psg.com/~zinin/ Thursday, May 13, 2004, 4:47:08 AM, Abhishek Mittal wrote: > Hi All, > I have one observation other then routing issues.Sorry for discussing it here. > Many times i have observed that telnet session thru vty shows user > connected for more then the exec-timeout.Although we have given the exec > timeout command in line vty. > Some log is from route-views.oregon-ix.net (Route-Server) > route-views.oregon-ix.net>sh users > Line User Host(s) Idle Location > 2 vty 0 idle 00:00:06 herprd18.nss.rr.com > 3 vty 1 idle 1d18h 203.115.112.148 > 4 vty 2 idle 07:54:45 nbc1.betaclub.org > 5 vty 3 idle 00:00:03 208.35.10.30 > 7 vty 5 rviews idle 00:01:30 bzq-165-45.dsl.bezeqint.net > Interface User Mode Idle Peer Address > route-views.oregon-ix.net> > In above log, vty 1 is showing idle and no user name is showing for this.I > think , this route-server admin must given the exec-timeout command for vty > sessions. But still it is showing the session more then 1day 18 hrs old. > This problem I have observed in many cisco IOS version.And due to this > behavior , we had reboot our one of 3660 router. > Can any one tell me , is it a bug or some thing else?Why it happens? > Thanks in advance. > Regards > Abhishek Mittal > --------------------------------- > Do you Yahoo!? > Yahoo! Movies - Buy advance tickets for 'Shrek 2' _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu May 13 14:32:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03526 for ; Thu, 13 May 2004 14:32: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 1BOKne-0002gr-AM for routing-discussion-archive@odin.ietf.org; Thu, 13 May 2004 14:19:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DIJIMB010337 for routing-discussion-archive@odin.ietf.org; Thu, 13 May 2004 14:19:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOKKR-0006bY-D5; Thu, 13 May 2004 13:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJpy-0001zH-G9 for routing-discussion@optimus.ietf.org; Thu, 13 May 2004 13:17:38 -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 NAA24772 for ; Thu, 13 May 2004 13:17: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 1BOJpw-0000A9-Hl for routing-discussion@ietf.org; Thu, 13 May 2004 13:17:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOJos-0007NX-00 for routing-discussion@ietf.org; Thu, 13 May 2004 13:16:31 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BOJo9-0006oT-00 for routing-discussion@ietf.org; Thu, 13 May 2004 13:15:45 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOJo9-000Bfn-5t; Thu, 13 May 2004 17:15:45 +0000 Date: Thu, 13 May 2004 10:15:43 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1727441504.20040513101543@psg.com> To: Abhishek Mittal CC: routing-discussion@ietf.org Subject: Re: vty session gets hang In-Reply-To: <20040513114708.96392.qmail@web40308.mail.yahoo.com> References: <20040513114708.96392.qmail@web40308.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 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: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Abhishek, This is _really_ a wrong forum for this question. Please take it to your vendor's technical support, or comp.dcom.sys.cisco or the cisco-nsp mailing list. -- Alex http://www.psg.com/~zinin/ Thursday, May 13, 2004, 4:47:08 AM, Abhishek Mittal wrote: > Hi All, > I have one observation other then routing issues.Sorry for discussing it here. > Many times i have observed that telnet session thru vty shows user > connected for more then the exec-timeout.Although we have given the exec > timeout command in line vty. > Some log is from route-views.oregon-ix.net (Route-Server) > route-views.oregon-ix.net>sh users > Line User Host(s) Idle Location > 2 vty 0 idle 00:00:06 herprd18.nss.rr.com > 3 vty 1 idle 1d18h 203.115.112.148 > 4 vty 2 idle 07:54:45 nbc1.betaclub.org > 5 vty 3 idle 00:00:03 208.35.10.30 > 7 vty 5 rviews idle 00:01:30 bzq-165-45.dsl.bezeqint.net > Interface User Mode Idle Peer Address > route-views.oregon-ix.net> > In above log, vty 1 is showing idle and no user name is showing for this.I > think , this route-server admin must given the exec-timeout command for vty > sessions. But still it is showing the session more then 1day 18 hrs old. > This problem I have observed in many cisco IOS version.And due to this > behavior , we had reboot our one of 3660 router. > Can any one tell me , is it a bug or some thing else?Why it happens? > Thanks in advance. > Regards > Abhishek Mittal > --------------------------------- > Do you Yahoo!? > Yahoo! Movies - Buy advance tickets for 'Shrek 2' _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon May 17 03:28:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04074 for ; Mon, 17 May 2004 03: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 1BPcRo-0005NJ-DN; Mon, 17 May 2004 03: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 1BPcMh-0004ig-Qw for routing-discussion@optimus.ietf.org; Mon, 17 May 2004 03:16: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 DAA03599 for ; Mon, 17 May 2004 03:16:46 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcMf-00078x-II for routing-discussion@ietf.org; Mon, 17 May 2004 03:16:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcLh-0006r7-00 for routing-discussion@ietf.org; Mon, 17 May 2004 03:15:45 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BPcLG-0006ZU-00 for routing-discussion@ietf.org; Mon, 17 May 2004 03:15:18 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H7F2v13162; Mon, 17 May 2004 10:15:08 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 10:14:32 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4H7EWAZ020549; Mon, 17 May 2004 10:14:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00NlBTu9; Mon, 17 May 2004 10:14:31 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H7EUH20874; Mon, 17 May 2004 10:14:30 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 02:14:29 -0500 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Updated version posted: draft-kompella-zinin-early-allocation-01.txt Date: Mon, 17 May 2004 02:14:29 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A37@daebe009.americas.nokia.com> Thread-Topic: Updated version posted: draft-kompella-zinin-early-allocation-01.txt Thread-Index: AcQxeIb86uFWyjzQQa+Ruw1HoX55XwKZL09g To: , X-OriginalArrivalTime: 17 May 2004 07:14:29.0771 (UTC) FILETIME=[98551DB0:01C43BDE] 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex, The changes look good to me. Minor points.. - The draft needs to update the internet draft template. "This document is an Internet-Draft and is in full=20 conformance with all provisions of Section 10 of=20 RFC2026." should be replaced with "By submitting=20 this Internet-Draft, I certify that any applicable=20 patent or other IPR claims of which I am aware have=20 been disclosed, and any of which I become aware will=20 be disclosed, in accordance with RFC 3668." - Also it should include the Intellectual Property Statement at the end. Regards Mukesh > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of ext Alex Zinin > Sent: Monday, May 03, 2004 6:30 PM > To: routing-discussion@ietf.org > Subject: Updated version posted: > draft-kompella-zinin-early-allocation-01.txt >=20 >=20 > Folks- >=20 > Kireeti and I updated the draft based on the comments we got=20 > via e-mail and at > the meeting in Seoul. Please check the new rev. We will be=20 > asking Bill to Last > Call the document within a few weeks. Send comments to=20 > routing-discussion@ietf.org, > please. >=20 > The draft is available at: >=20 > =20 > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early > -allocation-01.txt >=20 > For your convenience, the htmldiff is available at: > =20 > =20 > http://www.psg.com/~zinin/ietf/draft-kompella-zinin-early-allo > cation-00-01-diff.html > =20 > Abstract from the draft: >=20 > 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. >=20 > --=20 > Alex > http://www.psg.com/~zinin/ >=20 >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion >=20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon May 17 03:32:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04332 for ; Mon, 17 May 2004 03:32: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 1BPcXn-00062w-Bu for routing-discussion-archive@odin.ietf.org; Mon, 17 May 2004 03:28:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H7SFso023243 for routing-discussion-archive@odin.ietf.org; Mon, 17 May 2004 03:28:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcRo-0005NJ-DN; Mon, 17 May 2004 03: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 1BPcMh-0004ig-Qw for routing-discussion@optimus.ietf.org; Mon, 17 May 2004 03:16: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 DAA03599 for ; Mon, 17 May 2004 03:16:46 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcMf-00078x-II for routing-discussion@ietf.org; Mon, 17 May 2004 03:16:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcLh-0006r7-00 for routing-discussion@ietf.org; Mon, 17 May 2004 03:15:45 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BPcLG-0006ZU-00 for routing-discussion@ietf.org; Mon, 17 May 2004 03:15:18 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H7F2v13162; Mon, 17 May 2004 10:15:08 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 10:14:32 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4H7EWAZ020549; Mon, 17 May 2004 10:14:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00NlBTu9; Mon, 17 May 2004 10:14:31 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H7EUH20874; Mon, 17 May 2004 10:14:30 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 02:14:29 -0500 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Updated version posted: draft-kompella-zinin-early-allocation-01.txt Date: Mon, 17 May 2004 02:14:29 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A37@daebe009.americas.nokia.com> Thread-Topic: Updated version posted: draft-kompella-zinin-early-allocation-01.txt Thread-Index: AcQxeIb86uFWyjzQQa+Ruw1HoX55XwKZL09g To: , X-OriginalArrivalTime: 17 May 2004 07:14:29.0771 (UTC) FILETIME=[98551DB0:01C43BDE] 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex, The changes look good to me. Minor points.. - The draft needs to update the internet draft template. "This document is an Internet-Draft and is in full=20 conformance with all provisions of Section 10 of=20 RFC2026." should be replaced with "By submitting=20 this Internet-Draft, I certify that any applicable=20 patent or other IPR claims of which I am aware have=20 been disclosed, and any of which I become aware will=20 be disclosed, in accordance with RFC 3668." - Also it should include the Intellectual Property Statement at the end. Regards Mukesh > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of ext Alex Zinin > Sent: Monday, May 03, 2004 6:30 PM > To: routing-discussion@ietf.org > Subject: Updated version posted: > draft-kompella-zinin-early-allocation-01.txt >=20 >=20 > Folks- >=20 > Kireeti and I updated the draft based on the comments we got=20 > via e-mail and at > the meeting in Seoul. Please check the new rev. We will be=20 > asking Bill to Last > Call the document within a few weeks. Send comments to=20 > routing-discussion@ietf.org, > please. >=20 > The draft is available at: >=20 > =20 > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early > -allocation-01.txt >=20 > For your convenience, the htmldiff is available at: > =20 > =20 > http://www.psg.com/~zinin/ietf/draft-kompella-zinin-early-allo > cation-00-01-diff.html > =20 > Abstract from the draft: >=20 > 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. >=20 > --=20 > Alex > http://www.psg.com/~zinin/ >=20 >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion >=20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon May 17 04:09:56 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06227 for ; Mon, 17 May 2004 04:09: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 1BPd2e-00028J-HC; Mon, 17 May 2004 04:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcyN-0001cO-Rq for routing-discussion@optimus.ietf.org; Mon, 17 May 2004 03:55: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 DAA05324 for ; Mon, 17 May 2004 03:55:42 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcyL-0003mn-9M for routing-discussion@ietf.org; Mon, 17 May 2004 03:55:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcxP-0003Rj-00 for routing-discussion@ietf.org; Mon, 17 May 2004 03:54:44 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BPcwR-00038E-00 for routing-discussion@ietf.org; Mon, 17 May 2004 03:53:43 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H7rcv09476; Mon, 17 May 2004 10:53:38 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 10:53:30 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4H7rUJ2001936; Mon, 17 May 2004 10:53:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00dBzzg8; Mon, 17 May 2004 10:53:30 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H7TTH00202; Mon, 17 May 2004 10:29:29 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 02:29:28 -0500 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Updated version posted: draft-kompella-zinin-early-allocation-01.txt Date: Mon, 17 May 2004 02:29:28 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A37@daebe009.americas.nokia.com> Thread-Topic: Updated version posted: draft-kompella-zinin-early-allocation-01.txt Thread-Index: AcQxeIb86uFWyjzQQa+Ruw1HoX55XwKZL09g To: , X-OriginalArrivalTime: 17 May 2004 07:29:28.0788 (UTC) FILETIME=[B0303940:01C43BE0] 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex, The changes look good to me. Minor points.. - The draft needs to update the internet draft template. "This document is an Internet-Draft and is in full=20 conformance with all provisions of Section 10 of=20 RFC2026." should be replaced with "By submitting=20 this Internet-Draft, I certify that any applicable=20 patent or other IPR claims of which I am aware have=20 been disclosed, and any of which I become aware will=20 be disclosed, in accordance with RFC 3668." - Also it should include the Intellectual Property Statement at the end. Regards Mukesh > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of ext Alex Zinin > Sent: Monday, May 03, 2004 6:30 PM > To: routing-discussion@ietf.org > Subject: Updated version posted: > draft-kompella-zinin-early-allocation-01.txt >=20 >=20 > Folks- >=20 > Kireeti and I updated the draft based on the comments we got=20 > via e-mail and at > the meeting in Seoul. Please check the new rev. We will be=20 > asking Bill to Last > Call the document within a few weeks. Send comments to=20 > routing-discussion@ietf.org, > please. >=20 > The draft is available at: >=20 > =20 > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early > -allocation-01.txt >=20 > For your convenience, the htmldiff is available at: > =20 > =20 > http://www.psg.com/~zinin/ietf/draft-kompella-zinin-early-allo > cation-00-01-diff.html > =20 > Abstract from the draft: >=20 > 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. >=20 > --=20 > Alex > http://www.psg.com/~zinin/ >=20 >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion >=20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon May 17 04:14:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06471 for ; Mon, 17 May 2004 04:14: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 1BPdBf-0003Yt-CB for routing-discussion-archive@odin.ietf.org; Mon, 17 May 2004 04:09:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H89RXx013687 for routing-discussion-archive@odin.ietf.org; Mon, 17 May 2004 04:09:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPd2e-00028J-HC; Mon, 17 May 2004 04:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcyN-0001cO-Rq for routing-discussion@optimus.ietf.org; Mon, 17 May 2004 03:55: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 DAA05324 for ; Mon, 17 May 2004 03:55:42 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcyL-0003mn-9M for routing-discussion@ietf.org; Mon, 17 May 2004 03:55:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcxP-0003Rj-00 for routing-discussion@ietf.org; Mon, 17 May 2004 03:54:44 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BPcwR-00038E-00 for routing-discussion@ietf.org; Mon, 17 May 2004 03:53:43 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H7rcv09476; Mon, 17 May 2004 10:53:38 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 10:53:30 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4H7rUJ2001936; Mon, 17 May 2004 10:53:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00dBzzg8; Mon, 17 May 2004 10:53:30 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H7TTH00202; Mon, 17 May 2004 10:29:29 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 02:29:28 -0500 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Updated version posted: draft-kompella-zinin-early-allocation-01.txt Date: Mon, 17 May 2004 02:29:28 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A37@daebe009.americas.nokia.com> Thread-Topic: Updated version posted: draft-kompella-zinin-early-allocation-01.txt Thread-Index: AcQxeIb86uFWyjzQQa+Ruw1HoX55XwKZL09g To: , X-OriginalArrivalTime: 17 May 2004 07:29:28.0788 (UTC) FILETIME=[B0303940:01C43BE0] 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex, The changes look good to me. Minor points.. - The draft needs to update the internet draft template. "This document is an Internet-Draft and is in full=20 conformance with all provisions of Section 10 of=20 RFC2026." should be replaced with "By submitting=20 this Internet-Draft, I certify that any applicable=20 patent or other IPR claims of which I am aware have=20 been disclosed, and any of which I become aware will=20 be disclosed, in accordance with RFC 3668." - Also it should include the Intellectual Property Statement at the end. Regards Mukesh > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of ext Alex Zinin > Sent: Monday, May 03, 2004 6:30 PM > To: routing-discussion@ietf.org > Subject: Updated version posted: > draft-kompella-zinin-early-allocation-01.txt >=20 >=20 > Folks- >=20 > Kireeti and I updated the draft based on the comments we got=20 > via e-mail and at > the meeting in Seoul. Please check the new rev. We will be=20 > asking Bill to Last > Call the document within a few weeks. Send comments to=20 > routing-discussion@ietf.org, > please. >=20 > The draft is available at: >=20 > =20 > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early > -allocation-01.txt >=20 > For your convenience, the htmldiff is available at: > =20 > =20 > http://www.psg.com/~zinin/ietf/draft-kompella-zinin-early-allo > cation-00-01-diff.html > =20 > Abstract from the draft: >=20 > 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. >=20 > --=20 > Alex > http://www.psg.com/~zinin/ >=20 >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion >=20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue May 18 18:24:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24699 for ; Tue, 18 May 2004 18:24: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 1BQCqc-0003rI-Ow; Tue, 18 May 2004 18:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCi7-000749-El for routing-discussion@optimus.ietf.org; Tue, 18 May 2004 18:05: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 SAA22739 for ; Tue, 18 May 2004 18:05: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 1BQCi4-00013j-Kz for routing-discussion@ietf.org; Tue, 18 May 2004 18:05:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQChG-00010g-00 for routing-discussion@ietf.org; Tue, 18 May 2004 18:04:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BQCgV-0000xb-00 for routing-discussion@ietf.org; Tue, 18 May 2004 18:03:39 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQCgV-000IBZ-KE for routing-discussion@ietf.org; Tue, 18 May 2004 22:03:39 +0000 Date: Tue, 18 May 2004 15:03:38 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <879614611.20040518150338@psg.com> To: routing-discussion@ietf.org Subject: Review Request: draft-hardie-bounded-longest-match-05.txt 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 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- I've received a request to progress draft-hardie-bounded-longest-match-05.txt, "Bounding Longest Match", to the INFORMATIONAL RFC status as an individual submission. To ensure proper IETF community review, I am soliciting comments on this document. Please send your comments to the routing-discussion@ietf.org mailing list by June 1st, 2004. The document is available at: http://www.ietf.org/internet-drafts/draft-hardie-bounded-longest-match-05.txt The abstract of the document: Some ASes currently use length-based filters to manage the size of the routing table they use and propagate. This draft explores an alternative to length-based filters which allows for more automatic configuration and which provides for better redundancy. Rather than use a filter, this draft proposes a method of modifying the BGP longest match algorithm by setting a bound on the prefix lengths eligible for preference. A bound would operate on long prefixes when covering route announcements are available; in certain circumstances it would cause a router to prefer an aggregate over a more specific route announcement. -- Alex IETF RTG Area co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue May 18 18:31:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25179 for ; Tue, 18 May 2004 18:31: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 1BQD0W-0008DS-Hb for routing-discussion-archive@odin.ietf.org; Tue, 18 May 2004 18:24:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IMOK61031549 for routing-discussion-archive@odin.ietf.org; Tue, 18 May 2004 18:24:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCqc-0003rI-Ow; Tue, 18 May 2004 18:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCi7-000749-El for routing-discussion@optimus.ietf.org; Tue, 18 May 2004 18:05: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 SAA22739 for ; Tue, 18 May 2004 18:05: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 1BQCi4-00013j-Kz for routing-discussion@ietf.org; Tue, 18 May 2004 18:05:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQChG-00010g-00 for routing-discussion@ietf.org; Tue, 18 May 2004 18:04:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BQCgV-0000xb-00 for routing-discussion@ietf.org; Tue, 18 May 2004 18:03:39 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQCgV-000IBZ-KE for routing-discussion@ietf.org; Tue, 18 May 2004 22:03:39 +0000 Date: Tue, 18 May 2004 15:03:38 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <879614611.20040518150338@psg.com> To: routing-discussion@ietf.org Subject: Review Request: draft-hardie-bounded-longest-match-05.txt 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 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- I've received a request to progress draft-hardie-bounded-longest-match-05.txt, "Bounding Longest Match", to the INFORMATIONAL RFC status as an individual submission. To ensure proper IETF community review, I am soliciting comments on this document. Please send your comments to the routing-discussion@ietf.org mailing list by June 1st, 2004. The document is available at: http://www.ietf.org/internet-drafts/draft-hardie-bounded-longest-match-05.txt The abstract of the document: Some ASes currently use length-based filters to manage the size of the routing table they use and propagate. This draft explores an alternative to length-based filters which allows for more automatic configuration and which provides for better redundancy. Rather than use a filter, this draft proposes a method of modifying the BGP longest match algorithm by setting a bound on the prefix lengths eligible for preference. A bound would operate on long prefixes when covering route announcements are available; in certain circumstances it would cause a router to prefer an aggregate over a more specific route announcement. -- Alex IETF RTG Area co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed May 19 09:03:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08063 for ; Wed, 19 May 2004 09:03: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 1BQQLU-0004Sv-IL; Wed, 19 May 2004 08:38:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQPxI-0001uS-Al for routing-discussion@optimus.ietf.org; Wed, 19 May 2004 08:13: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 IAA04832 for ; Wed, 19 May 2004 08:13: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 1BQPxH-0000D5-Ap for routing-discussion@ietf.org; Wed, 19 May 2004 08:13:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQPwK-00001a-00 for routing-discussion@ietf.org; Wed, 19 May 2004 08:12:52 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BQPvN-0007VW-00 for routing-discussion@ietf.org; Wed, 19 May 2004 08:11:54 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4JCBJ314386; Wed, 19 May 2004 15:11:19 +0300 Date: Wed, 19 May 2004 15:11:19 +0300 (EEST) From: Pekka Savola To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: Updated version posted: draft-kompella-zinin-early-allocation-01.txt In-Reply-To: <19150967.20040503182939@psg.com> Message-ID: 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: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Mon, 3 May 2004, Alex Zinin wrote: > 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 routing-discussion@ietf.org, > please. Seems like good stuff. First time I read this -- a few rather minor comments below. semi-substantial ---------------- If conditions (a) or (b) are not met, then the processes in this memo do not apply. ==> why do not conditions (c) and (d) be considered as blocking? What's the difference with these processed? Or do you mean that (a) or (b) are the "show-stopper" issues which MUST have been fulfilled before even considering this approach, and c)-d) must be filled in any case, but that's then up to the WG (and chairs) whether they consider these filled or not? The similar comment applies to: 2) The WG chairs determine whether the conditions for early allocations described in section 2 are met, particularly conditions (c) and (d). .... [3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004 ==> this wasn't used in the body; remove or add reference? editorial --------- performs allocation. However, in situations where codepoints are a scarce resource and/or the IETF community is willing to retain tight control of the protocol, policies such as IESG Approval, IETF ==> s/is willing/wants/ (there's a nuance difference but I think the latter is closer) 2. IANA allocates codepoints silently used for other extensions. Different extensions will collide. ==> please reword, I didn't quite understand the "silently used" parts. Prefix with "that someone has illegitimately" ? 1) The authors (editors) of the document submit a request for early allocation the Working Group chairs, specifying which code points ==> s/allocation/allocation to/ immediately obvious: depletion of code space by early allocations; and process overburden of IANA itself. The processes described here ==> I find "process overburden" a bit difficult to parse. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed May 19 09:07:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08688 for ; Wed, 19 May 2004 09:07: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 1BQQjL-0001Vx-P8 for routing-discussion-archive@odin.ietf.org; Wed, 19 May 2004 09:03:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JD3Vl8005743 for routing-discussion-archive@odin.ietf.org; Wed, 19 May 2004 09:03:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQQLU-0004Sv-IL; Wed, 19 May 2004 08:38:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQPxI-0001uS-Al for routing-discussion@optimus.ietf.org; Wed, 19 May 2004 08:13: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 IAA04832 for ; Wed, 19 May 2004 08:13: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 1BQPxH-0000D5-Ap for routing-discussion@ietf.org; Wed, 19 May 2004 08:13:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQPwK-00001a-00 for routing-discussion@ietf.org; Wed, 19 May 2004 08:12:52 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BQPvN-0007VW-00 for routing-discussion@ietf.org; Wed, 19 May 2004 08:11:54 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4JCBJ314386; Wed, 19 May 2004 15:11:19 +0300 Date: Wed, 19 May 2004 15:11:19 +0300 (EEST) From: Pekka Savola To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: Updated version posted: draft-kompella-zinin-early-allocation-01.txt In-Reply-To: <19150967.20040503182939@psg.com> Message-ID: 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: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Mon, 3 May 2004, Alex Zinin wrote: > 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 routing-discussion@ietf.org, > please. Seems like good stuff. First time I read this -- a few rather minor comments below. semi-substantial ---------------- If conditions (a) or (b) are not met, then the processes in this memo do not apply. ==> why do not conditions (c) and (d) be considered as blocking? What's the difference with these processed? Or do you mean that (a) or (b) are the "show-stopper" issues which MUST have been fulfilled before even considering this approach, and c)-d) must be filled in any case, but that's then up to the WG (and chairs) whether they consider these filled or not? The similar comment applies to: 2) The WG chairs determine whether the conditions for early allocations described in section 2 are met, particularly conditions (c) and (d). .... [3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004 ==> this wasn't used in the body; remove or add reference? editorial --------- performs allocation. However, in situations where codepoints are a scarce resource and/or the IETF community is willing to retain tight control of the protocol, policies such as IESG Approval, IETF ==> s/is willing/wants/ (there's a nuance difference but I think the latter is closer) 2. IANA allocates codepoints silently used for other extensions. Different extensions will collide. ==> please reword, I didn't quite understand the "silently used" parts. Prefix with "that someone has illegitimately" ? 1) The authors (editors) of the document submit a request for early allocation the Working Group chairs, specifying which code points ==> s/allocation/allocation to/ immediately obvious: depletion of code space by early allocations; and process overburden of IANA itself. The processes described here ==> I find "process overburden" a bit difficult to parse. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon May 24 12:34:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18350 for ; Mon, 24 May 2004 12:34: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 1BSIH3-00057J-F8; Mon, 24 May 2004 12: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 1BSHtK-0000jg-2E for routing-discussion@optimus.ietf.org; Mon, 24 May 2004 12:01: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 MAA16521 for ; Mon, 24 May 2004 12:01: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 1BSHtI-00023m-M1 for routing-discussion@ietf.org; Mon, 24 May 2004 12:01:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSHsL-0001xg-00 for routing-discussion@ietf.org; Mon, 24 May 2004 12:00: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 1BSHrj-0001r0-00 for routing-discussion@ietf.org; Mon, 24 May 2004 11:59:51 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 18D842D485A; Mon, 24 May 2004 11:59:21 -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 09321-01-10; Mon, 24 May 2004 11:59:09 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 989CD2D481C; Mon, 24 May 2004 11:59:09 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i4OFx9T14023; Mon, 24 May 2004 11:59:09 -0400 (EDT) Date: Mon, 24 May 2004 11:59:09 -0400 From: Jeffrey Haas To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Review Request: draft-hardie-bounded-longest-match-05.txt Message-ID: <20040524155909.GE11019@nexthop.com> References: <879614611.20040518150338@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <879614611.20040518150338@psg.com> 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: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , I've covered document nits off-list. I have some concerns which I would like the broader routing-discussion to consider along with the authors. NO_EXPORT solves the problem about controlling distribution, but it also overloads an existing signalling mechanism. I have some concerns that it would cause NO_INSTALL to also be used in some spots it wasn't meant for. Could we get some clarification on how we're meant to distinguish NO_EXPORT for bounded longest match vs. generic policy uses? The mechanism has some of the issues that other forms of aggregation have. If you configure an aggregate and use AS-SET based aggregation rules, you are presuming anyone who is an aggregate contributor gets all of the more specifics. This is, I believe, generally true for brief aggregation rules as well. So, in this case, if you have a somehwat contrived situation: D | A ----- B ----- C | | +---------------+ A has 10/8 D has 10.0.1/24 B declines to gives A transit to D directly. (Does not export 10.0.1/24 to A) C thus receives: 10/8 A 10/8 B A 10.0.1.24 B D Applying the rules for bounded longest match, we never send our less specific contributor, A, the longer route. Thus we deny him reachability to D. This is admittedly a "it hurts to do this, don't do that", but unlike configured aggregation, we have no way to make sure that the less specific route gets more specifics. We can't configure the aggregate contributors to only be sent to those we know contributed to it - we're prevented from even getting the more specific at all. This might be solvable if C sends overlapping routes to less specific contributors - i.e. instead of using NO_EXPORT, only send the more specifics to those who are sending us overlapping routes. This now means we would have to muck in our adj-rib-out as well as adj-rib-in. Is this a show-stopper? Don't know. But it's also reasonably complicated. And I'm not sure if this really saves us much that good configured policy wouldn't do in the first place. The base BGP specification has also had rules in there for some time about not basing the decision for what you do based on the presence or absence of other routes. When weird things like this are in the spec, it often implies one of two things: o This is dangerous, but it's up to you to figure out why o This isn't dangerous, it just generates churn. o The authors couldn't come to consensus and were brushing this issue under the carpet and letting subsequent generations of protocol developers trip over them. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon May 24 12:40:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18594 for ; Mon, 24 May 2004 12:40: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 1BSIOk-0007Mc-ML for routing-discussion-archive@odin.ietf.org; Mon, 24 May 2004 12:33:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OGXwtb028307 for routing-discussion-archive@odin.ietf.org; Mon, 24 May 2004 12:33:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSIH3-00057J-F8; Mon, 24 May 2004 12: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 1BSHtK-0000jg-2E for routing-discussion@optimus.ietf.org; Mon, 24 May 2004 12:01: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 MAA16521 for ; Mon, 24 May 2004 12:01: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 1BSHtI-00023m-M1 for routing-discussion@ietf.org; Mon, 24 May 2004 12:01:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSHsL-0001xg-00 for routing-discussion@ietf.org; Mon, 24 May 2004 12:00: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 1BSHrj-0001r0-00 for routing-discussion@ietf.org; Mon, 24 May 2004 11:59:51 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 18D842D485A; Mon, 24 May 2004 11:59:21 -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 09321-01-10; Mon, 24 May 2004 11:59:09 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 989CD2D481C; Mon, 24 May 2004 11:59:09 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i4OFx9T14023; Mon, 24 May 2004 11:59:09 -0400 (EDT) Date: Mon, 24 May 2004 11:59:09 -0400 From: Jeffrey Haas To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Review Request: draft-hardie-bounded-longest-match-05.txt Message-ID: <20040524155909.GE11019@nexthop.com> References: <879614611.20040518150338@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <879614611.20040518150338@psg.com> 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: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , I've covered document nits off-list. I have some concerns which I would like the broader routing-discussion to consider along with the authors. NO_EXPORT solves the problem about controlling distribution, but it also overloads an existing signalling mechanism. I have some concerns that it would cause NO_INSTALL to also be used in some spots it wasn't meant for. Could we get some clarification on how we're meant to distinguish NO_EXPORT for bounded longest match vs. generic policy uses? The mechanism has some of the issues that other forms of aggregation have. If you configure an aggregate and use AS-SET based aggregation rules, you are presuming anyone who is an aggregate contributor gets all of the more specifics. This is, I believe, generally true for brief aggregation rules as well. So, in this case, if you have a somehwat contrived situation: D | A ----- B ----- C | | +---------------+ A has 10/8 D has 10.0.1/24 B declines to gives A transit to D directly. (Does not export 10.0.1/24 to A) C thus receives: 10/8 A 10/8 B A 10.0.1.24 B D Applying the rules for bounded longest match, we never send our less specific contributor, A, the longer route. Thus we deny him reachability to D. This is admittedly a "it hurts to do this, don't do that", but unlike configured aggregation, we have no way to make sure that the less specific route gets more specifics. We can't configure the aggregate contributors to only be sent to those we know contributed to it - we're prevented from even getting the more specific at all. This might be solvable if C sends overlapping routes to less specific contributors - i.e. instead of using NO_EXPORT, only send the more specifics to those who are sending us overlapping routes. This now means we would have to muck in our adj-rib-out as well as adj-rib-in. Is this a show-stopper? Don't know. But it's also reasonably complicated. And I'm not sure if this really saves us much that good configured policy wouldn't do in the first place. The base BGP specification has also had rules in there for some time about not basing the decision for what you do based on the presence or absence of other routes. When weird things like this are in the spec, it often implies one of two things: o This is dangerous, but it's up to you to figure out why o This isn't dangerous, it just generates churn. o The authors couldn't come to consensus and were brushing this issue under the carpet and letting subsequent generations of protocol developers trip over them. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon May 31 08:40:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16764 for ; Mon, 31 May 2004 08:40:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUm0G-00052z-JK; Mon, 31 May 2004 08:34:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUlsP-0004BI-Pi for routing-discussion@megatron.ietf.org; Mon, 31 May 2004 08:26: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 IAA16255 for ; Mon, 31 May 2004 08:26: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 1BUlsP-0002Gg-84 for routing-discussion@ietf.org; Mon, 31 May 2004 08:26:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUlrU-0001xU-00 for routing-discussion@ietf.org; Mon, 31 May 2004 08:25:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BUlqt-0001cb-00 for routing-discussion@ietf.org; Mon, 31 May 2004 08:25:15 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 31 May 2004 08:25:16 -0400 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 i4VCOf2V004605; Mon, 31 May 2004 08:24:41 -0400 (EDT) Received: from localhost (rtp-vpn1-84.cisco.com [10.82.224.84]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA10344; Mon, 31 May 2004 08:24:41 -0400 (EDT) Date: Mon, 31 May 2004 08:24:41 -0400 (Eastern Daylight Time) From: Russ White To: Jeffrey Haas In-Reply-To: <20040524155909.GE11019@nexthop.com> Message-ID: References: <879614611.20040518150338@psg.com> <20040524155909.GE11019@nexthop.com> X-X-Sender: ruwhite@shako.cisco.com 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: Alex Zinin , routing-discussion@ietf.org Subject: Re: Review Request: draft-hardie-bounded-longest-match-05.txt X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Area General mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > NO_EXPORT solves the problem about controlling distribution, but it also > overloads an existing signalling mechanism. I have some concerns that it > would cause NO_INSTALL to also be used in some spots it wasn't meant for. > Could we get some clarification on how we're meant to distinguish > NO_EXPORT for bounded longest match vs. generic policy uses? We could define a new community, but we were trying to avoid doing so in the case where one exists that already does what we want. When this draft was first published, there was a new community involved, and we removed it because of feedback.... :-) > The mechanism has some of the issues that other forms of aggregation > have. If you configure an aggregate and use AS-SET based aggregation > rules, you are presuming anyone who is an aggregate contributor gets all > of the more specifics. This is, I believe, generally true for brief > aggregation rules as well. This is true for aggregation in general, I believe. > So, in this case, if you have a somehwat contrived situation: > > D > | > A ----- B ----- C > | | > +---------------+ > > A has 10/8 > > D has 10.0.1/24 > > B declines to gives A transit to D directly. (Does not export 10.0.1/24 to A) > > C thus receives: > 10/8 A > 10/8 B A > 10.0.1.24 B D > > Applying the rules for bounded longest match, we never send our less > specific contributor, A, the longer route. Thus we deny him reachability > to D. > > This is admittedly a "it hurts to do this, don't do that", but unlike > configured aggregation, we have no way to make sure that the less > specific route gets more specifics. We can't configure the aggregate > contributors to only be sent to those we know contributed to it - we're > prevented from even getting the more specific at all. Two points: -- How would we solve this with manually configured aggregation? By configuring an exception to that aggregation, correct? If C is aware of the problem, and manually configures an exception to the aggregation to work around B's policy no direct transit for D to A, then C could also manually configure an exception list for longest match bounding, accomplishing the same thing. The configuration for the two should be the same. -- How does C know about this problem? If we inject another hop between A and C, C isn't the direct upstream for either A or D, and thus has no interest in fixing it by working around B's policies, correct? This isn't a problem with bounding the longest match, in other words, it's a problem with differing local policies (aggregation and no direct transit) in conflict with one another, really. The only real solution here is to disallow aggregation. > This might be solvable if C sends overlapping routes to less specific > contributors - i.e. instead of using NO_EXPORT, only send the more > specifics to those who are sending us overlapping routes. In other words, if any peer is sending you any component of a longer prefix, then always send them prefixes within the same block of addresses. This is, as you point out, very complex, and it's a solution to a policy problem, not a routing problem, per se. Of course, if we are going to incur the complexity of these rules for all aggregation, in the BGP base spec, to solve the problem with general aggregation, then we could just ride on that rule change in this draft. IMHO, there are no more difficulties with bounding the longest match than any other filtering or aggregation mechanism (C could also be filtering the longer match at its border with A, simply because they don't want to accept prefixes of that length, or because they don't like one of the communities set on the prefix as they've received it, or for any other reason). As for NO_INSTALL, it's really an optimization, rather than anything else, so it's more local policy rather than something required/etc (?).... Can you expand on the types of specific rules you'd like to see? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion